Re: Getting all the IP address for a machine from code...
> It is possible to get interface lists on earlier versions (and I hope
> still current versions) using the ioctl interfaces described in Stevens.
> See also ifconfig.c source from various versions of FreeBSD :-).
I think Garret suggested that the ioctl method was deprecated?
I wrote some code just to figure out how the sysctl stuff is packed
'cos it's not that obvoius - I've included it below incase it might
be of use to someone.
David.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/*
* This is an example of how to find info about the currently configured
* interfaces.
*
* The code in rwhod and ifconfig if pretty hard to understand as it
* doesn't really exploit the structure of what you're returned. We use
* a sysctl to get the interface list, which returns a buffer with a
* list of things each starting with:
*
* msglen
* version
* type
*
* The generic type used to with this start in the kernel seems to be
* "struct rt_msghdr". For this sysctl we call it returns a message of
* type RTM_IFINFO followed by a list of RTM_NEWADDR for each interface.
* This corrisponds to the interface and each of the configurations you
* "put" on it with ifconfig.
*
* The RTM_IFINFO message contains a struct if_msghdr followed by a
* list of struct sockaddr. The RTM_NEWADDR contains a struct ifa_msghdr
* followed by a list of struct sockaddr.
*
* The struct sockaddr's sizes have been truncated to the nearest
* power of two into which the data will fit. The struct sockaddr's
* included depend on what is apropriate to this message. You can tell
* which of RTAX_* sockaddr's have been included by looking at the set
* bits of ifm_addrs or ifam_addrs, so you have to expand them out into
* an array of struct sockaddr's of size RTAX_MAX.
*/
void unpack_addrs(struct sockaddr *packed,struct sockaddr *unpacked,int rti_addrs);
void print_addrs(struct sockaddr *unpacked,int rti_addrs);
int
main(int argc, char **argv)
{
char *buf, *lim, *next; /* For sysctl */
size_t needed;
int mib[6];
struct rt_msghdr *rtm; /* For decoding messages */
struct if_msghdr *ifm;
struct ifa_msghdr *ifam;
struct sockaddr *packed_addr; /* For decoding addresses */
struct sockaddr unpacked_addr[RTAX_MAX];
mib[0] = CTL_NET;
mib[1] = PF_ROUTE;
mib[2] = 0;
mib[3] = AF_INET;
mib[4] = NET_RT_IFLIST;
mib[5] = 0;
if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0)
errx(1, "route-sysctl-estimate");
if ((buf = malloc(needed)) == NULL)
errx(1, "malloc");
if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0)
errx(1, "actual retrieval of interface table");
lim = buf + needed;
for( next = buf; next < lim; next += rtm->rtm_msglen ) {
rtm = (struct rt_msghdr *)next;
switch( rtm->rtm_type ) {
case RTM_IFINFO:
ifm = (struct if_msghdr *)next;
packed_addr = (struct sockaddr *)(next + sizeof(struct
if_msghdr));
printf("Found an interface.\n");
if( ifm->ifm_flags & IFF_UP )
printf("It is currently up.\n");
if( ifm->ifm_addrs != 0 ) {
printf("These addresses were available:\n");
unpack_addrs(packed_addr,unpacked_addr,
ifm->ifm_addrs);
print_addrs(unpacked_addr,ifm->ifm_addrs);
} else
printf("No addresses were available.\n");
break;
case RTM_NEWADDR:
ifam = (struct ifa_msghdr *)next;
packed_addr = (struct sockaddr *)(next + sizeof(struct
ifa_msghdr));
printf("Found extra addresses associated with interface.\n");
unpack_addrs(packed_addr,unpacked_addr,
ifam->ifam_addrs);
print_addrs(unpacked_addr,ifam->ifam_addrs);
break;
default:
errx(1, "unexpected rtm type");
}
}
exit(0);
}
#define ROUNDUP(a) \
((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long))
void
unpack_addrs(struct sockaddr *packed,struct sockaddr *unpacked,int rti_addrs)
{
int i;
for( i = 0; i < RTAX_MAX; i++ ) {
bzero(&unpacked[i],sizeof(unpacked[i]));
if( rti_addrs & (1sa_len));
}
}
}
void
print_addrs(struct sockaddr *unpacked,int r
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
using Brian's post since I don't have the original around ...
On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
>
> [ attribution missing, is it Poul-Henning Kamp's text? ]
>
> > The majority of these programs could be handled by adding
> > knowledge of "-" as a magic filename to fopen(3).
> [.]
> > At the same time I would really love if we implemented "|.*"
> > to mean "do an popen(3)" instead.
The only reasonable way to provide this functionality to apps not
wanting to reinvent it themselves without breaking those who feel
that files should be just that - files - is a _new_ function next
to fopen(3) named some rather alerting way like superduperopen(3)
with flags like SDO_KNOWS_STDIN, SDO_CAN_PIPEFROM,
SDO_CAN_PIPEINTO and whatever other extension you can think of.
32 of these new behaviour patterns should suffice for quite a
while. :)
This will collapse the "-" recognition and handling logic in
existing programs to passing a simple flag to a different
function (with only one more int parameter compared to fopen(3))
and leave those alone who just want to fopen(3) any file. And
when the options set is extended no app will "inherit" unwanted
and unexpected features turning out to be holes. Unless there's
a SDO_DO_ANY_PRESENT_AND_FUTURE_MAGIC flag passed with a value of
0x. But authors doing so will get what they deserve. :>
One could even think of switching to the new function "to be
ready" and passing a SDO_DONT_DO_ANY_MAGIC flag.
How much sense does it make to think about implementing tee and
select methods this way? Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"? The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames. '&' seems to be too, but could be used
rarely enough. And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.
e.g.
superduperopen("file1&file2", "a+", SDO_TEEFILES)
superduperopen("file1&file2", "r" , SDO_SELECT)
Semantics could be braindead simple: TEE will just dup any data
to every file specified and SELECT will have implicit priorities
since there's no logic doing round robing or something. This
will suffice for randomly filled input channels being fed more
alternatively rather than concurrently.
Of course the mode parameter from fopen(3) and the magicmask
parameter from superduperopen(3) (i.e. the second and third
parameters) have to pass certain checks. Nobody should try to
read from "|command". And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.
Feel free to correct the flag's data type. I have the feeling
not all int's have 32bits. :) Some other means of storage might
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting all the IP address for a machine from code...
On Sat, 16 Sep 2000, David Malone wrote: > > It is possible to get interface lists on earlier versions (and I hope > > still current versions) using the ioctl interfaces described in Stevens. > > See also ifconfig.c source from various versions of FreeBSD :-). > > I think Garret suggested that the ioctl method was deprecated? That said, the ioctl() method is probably also portable across platforms. Recommending the deprecating quasi-standard interfaces in favor of local interfaces for third-party application writers would probably be a mistake. Where it's not possible to perform the function with the portable API, fine, of course. :-) Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
> 32k directories in a directory
Hi, Ok, no laughing folks. I've run up against an application (which I do not have control over) that wants to create more than 32k directories in a directory. in syslimits.h I find: #define LINK_MAX32767 /* max file link count */ which I think is what I'm running up against. This is referenced in sys/ufs/ufs/ufs_vnops.c at which point EMLINK is returned. Yes, this is being done against a ufs filesystem. I also note some int32_t variables in the dir structures which worries me. Has anyone built a system which can support > 32k dirs in a dir, or have any ideas what is involved? The FAQ and handbook don't appear to address this anywhere. Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: > 32k directories in a directory
On Sat, Sep 16, 2000 at 03:06:06PM -0400, John DeBoskey wrote: > #define LINK_MAX32767 /* max file link count */ Looking at /usr/include/ufs/ufs/dinode.h, which seems to describe the format of the on-disk inode I see that di_nlink is a int16_t, for which the largest positive value is 32767. If you try increasing this things will almost certainly blow up. >Has anyone built a system which can support > 32k dirs in > a dir, or have any ideas what is involved? You really don't want to have a directory with 32K entries on a UFS filesystem - it will be painfully slow and inefficient. I've tried to clean up a news filesystem which had directories with large numbers of entries and you can only delete entries once every few seconds - in the end I unmounted the filesystem, clried the directory and fscked. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
device naming convention
What is the FreeBSD naming convention for devices of disk slices and labels? Considering my system is installed on the first partition of /dev/wd0 (non-dedicated), these are the block-device interfaces I have to my disk: wd0 wd0cwd0fwd0s1 wd0s1cwd0s1fwd0s2 wd0awd0dwd0gwd0s1awd0s1dwd0s1gwd0s3 wd0bwd0ewd0hwd0s1bwd0s1ewd0s1hwd0s4 Questions: 1. What are wd0[a-h] used for? 2. If wd0s1 is my first slice, why isn't it named wd0s0? 3. If I format wd0s2 as any type (Xenix for example), will /dev now contain wd0s2[a-h]? Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 doesn't span to the end of disk: 4. If I want to use /dev/wd0s2 as a raw slice for reading and writing, what are the steps to follow? 4a. Do I need to format the partition as any type? If so is there a recommended type (perhaps one which won't be recognised by the bootloader would be preferable)? 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a for reading and writing (of course, this is assuming block i/o of multiples of 512 bytes)? Lastly, where else could I have found this information other than asking on the FreeBSD mailing list? Thanks, Marc Tardif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panic key on std PC keyboard ....
Hi ... Does anyone know which key is the PNC key on a typical keyboard? This is the key which with sysctl machdep.enable_panic_key=1 should force a panic. Earlier today I found my machine wedged and had to power cycle to get unstuck. So for future reference, this will be very handy info. Thanks very much. --David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Panic key on std PC keyboard ....
On Sat, Sep 16, 2000 at 06:13:04PM -0400, David Bein wrote: > Does anyone know which key is the PNC key on a typical keyboard? > This is the key which with sysctl machdep.enable_panic_key=1 should force > a panic. Earlier today I found my machine wedged and had to power cycle > to get unstuck. So for future reference, this will be very handy info. Just grepping through /usr/share/syscons/keymaps/ it looks like the panic key isn't usually enabeled. So you have to enable the sysctl and edit a keymap to make some combination of keys panic the machine. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif writes: > What is the FreeBSD naming convention for devices of disk slices and > labels? Considering my system is installed on the first partition of > /dev/wd0 (non-dedicated), these are the block-device interfaces I > have to my disk: > > wd0 wd0cwd0fwd0s1 wd0s1cwd0s1fwd0s2 > wd0awd0dwd0gwd0s1awd0s1dwd0s1gwd0s3 > wd0bwd0ewd0hwd0s1bwd0s1ewd0s1hwd0s4 > > Questions: > 1. What are wd0[a-h] used for? For wd0sN[a-h] where N is number of first slice recognized as FreeBSD slice > 2. If wd0s1 is my first slice, why isn't it named wd0s0? wd0s0 == wd0 wd0s0a == wd0a > 3. If I format wd0s2 as any type (Xenix for example), >will /dev now contain wd0s2[a-h]? Content of /dev is totally undependent of any hardware and kernel conditions. Do yourself cd /dev ; ./MAKEDEV wd0s2h for wd0s2[a-h] entries > Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 > doesn't span to the end of disk: > 4. If I want to use /dev/wd0s2 as a raw slice for reading >and writing, what are the steps to follow? You can't write several blocks near /dev/wd0s2 beginning. Use /dev/wd0 with proper address > 4a. Do I need to format the partition as any type? If so > is there a recommended type (perhaps one which won't > be recognised by the bootloader would be preferable)? It depends on usage. And remember - kernel looks up every slice to find FreeBSD label - even if you mark it 0 (unused) > 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a > for reading and writing (of course, this is assuming > block i/o of multiples of 512 bytes)? You can do what you want, but remember, [a-h] can be used only if partitino have a FreeBSD label For example, for label on wd0s2 # some space not included in FreeBSD partition 514080 0 a: 514080 514080 b: 514080 1028160 you can use wd0s2a AND wd0s2 as different file systems IF you properly initialise with newfs. > Lastly, where else could I have found this information other > than asking on the FreeBSD mailing list? Read sources and experiment. BE AWARE - FreeBSD 4.X in difference with FreeBSD 2.2.X is highly unstable while experiment with labels -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
[ snip ] > > 1. What are wd0[a-h] used for? > For wd0sN[a-h] where N is number of first slice recognized > as FreeBSD slice > If I understand correctly, wd0[a-h] will be the same as wd0s3[a-h] in a situation where DOS is on first slice, Linux on second and FreeBSD on third, right? But what if the fourth slice is also FreeBSD? In such a case, I'll assume you meant "booted slice" instead of "first slice", where the slice selected when booting will be referred to by the OS as wd0[a-h] which would translate to "current slice". Confirmation of my assumption would be appreciated. > > 2. If wd0s1 is my first slice, why isn't it named wd0s0? > wd0s0 == wd0 > wd0s0a == wd0a > I somehow doubt that. Considering wd0s* goes from 1 to 4 inclusively, I would tend to believe the first slice is wd0s1. [ snip ] > > Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 > > doesn't span to the end of disk: > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > >and writing, what are the steps to follow? > You can't write several blocks near /dev/wd0s2 beginning. > Use /dev/wd0 with proper address > That is rather risky. Wouldn't it be safer to have a device name I could dedicate to some purpose. In such a case, I could chown the device to an appropriate username and group. Furthermore, I could avoid the unfortunate mistake of overwriting my current FreeBSD fs in case I get the addresses wrong. > > 4a. Do I need to format the partition as any type? If so > > is there a recommended type (perhaps one which won't > > be recognised by the bootloader would be preferable)? > It depends on usage. And remember - kernel looks up every > slice to find FreeBSD label - even if you mark it 0 (unused) > How does it depend on usage? Are some formats preferable for some specific usage (consider I'll only be using the raw interface to the device)? [ snip ] Thanks for the first message, Marc Tardif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif writes: > [ snip ] > > > 1. What are wd0[a-h] used for? > > For wd0sN[a-h] where N is number of first slice recognized > > as FreeBSD slice > > > If I understand correctly, wd0[a-h] will be the same as wd0s3[a-h] in a > situation where DOS is on first slice, Linux on second and FreeBSD on > third, right? But what if the fourth slice is also FreeBSD? In such a > case, I'll assume you meant "booted slice" instead of "first slice", where > the slice selected when booting will be referred to by the OS as wd0[a-h] > which would translate to "current slice". Confirmation of my assumption > would be appreciated. As far as I remember not booted, but first May be it is version dependant? > > > 2. If wd0s1 is my first slice, why isn't it named wd0s0? > > wd0s0 == wd0 > > wd0s0a == wd0a > I somehow doubt that. Considering wd0s* goes from 1 to 4 inclusively, I > would tend to believe the first slice is wd0s1. Bits in minor with slice number can be from 0 to 31 (5 bits). 0 is for wd0s0 == wd0 And lok at /dev/MAKEDEV > [ snip ] > > > Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 > > > doesn't span to the end of disk: > > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > > >and writing, what are the steps to follow? > > You can't write several blocks near /dev/wd0s2 beginning. > > Use /dev/wd0 with proper address > That is rather risky. Wouldn't it be safer to have a device name I could > dedicate to some purpose. In such a case, I could chown the device to an > appropriate username and group. Furthermore, I could avoid the unfortunate > mistake of overwriting my current FreeBSD fs in case I get the addresses > wrong. My tests in this area are old enough, may be up to 3.1 It depends on whether /dev/wd0s2 has a FreeBSD label or not. If pure MSDOS slice, it is not write protected, and in times I had some M$ slices I restored it by dd. Any slices that recognized with labels (not only FreeBSD labels, but FreeBSD take not care about whos labels are) have some write protected block so you can't restore, for example, boot loader by simlpe dd. In such a case you need use for example dd of=/dev/wd0 seek=(shift of slice from disk begin) > > > 4a. Do I need to format the partition as any type? If so > > > is there a recommended type (perhaps one which won't > > > be recognised by the bootloader would be preferable)? > > It depends on usage. And remember - kernel looks up every > > slice to find FreeBSD label - even if you mark it 0 (unused) > How does it depend on usage? Are some formats preferable for some specific > usage (consider I'll only be using the raw interface to the device)? Partition you mean is M$ partition? (slice in FBSD) or partition in FBSD slice? You are NOT restricted by FBSD slices to have ufs in. But if use some slice without ufs be aware from occasionaly create some pattern that FBSD think as label. May be just not use slice begin. If you mean FBSD partition, the first of them hase write protected blocks. I was not tested another. The same - just not use partition's begin. IMHO 8K, but I am not hard in this. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mergemaster RFC (long)
Greetings campers, Mergemaster first made its appearance as a port two years ago tomorrow, and became part of the FreeBSD source tree last October 20th. Lots of things have changed since the original version of the program (or script, whatever), and there are some proposals on the board for it that I'd really like to get some input on. For those that aren't aware, mm started its life kind of on a dare. My life before getting the full time job that I have now was mostly doing consulting work, so I did a lot of updates remotely. Making the system safe for remote upgrading has always been a major goal of mine. The proto-mergemaster was just a little script that I used because I got tired of forgetting the little bits and pieces. During a conversation on line about how the configuration system should be expanded, I mentioned that I had a little script that helped during upgrades, and a lot of people wanted a copy. Since I had to clean the code up anyway, and since certain people said it couldn't be done, I created what turned into the mergemaster we know and love today. I had some design goals when I started the project, most of which came from my background in doing remote upgrades. The first goal was to make mm as secure as possible. There are numerous precautions built in to avoid overwriting files inappropriately, avoid typical /tmp file overwriting exploits, etc. I also wanted it to be as independent as possible from having to know anything about specific files. This would allow it to continue to be useful no matter what got changed or upgraded. To accomplish this goal I mercilessly cribbed some ideas from Nik Clayton's make world page. The next goal was to make the program as simple as possible given the complexity of some of the stuff that it deals with. I tried to accomplish that by making it as unix like as possible, with tools, options, etc. that act as much like "regular" unix tools as my knowledge and ability allowed. Finally, one of the central design goals was to never take any action that the user didn't specifically request. ALL of the defaults in the program are to do nothing, because in almost all cases that's the safest thing to (not) do. That final goal has been compromised somewhat in the past year, as different people have requested various hacks to avoid having to look at certain files that they never want to upgrade. I'm uncomfortable with this for several reasons. First, because of the way mm works it's already possible (and in fact, desirable) to "hide" local modifications to files by keeping their cvs $FreeBSD ($Id) tags the same as the current version in source. In this way, you only have to deal with the file when there are actual updates, which I feel strongly is something you _should_ do anyway. However, over time I've come to accept the fact that mm now belongs more to the community than to me exclusively, so what *I* think you should do is less important than it was. The other struggle I'm having currently is that the thing is really becoming a beast. I wanted it to be small, simple and fast, and in the tradition of unix tools to do one thing and do it well. The thing already has WAY more options than I ever use, which isn't necessarily the ultimate barometer, but it is starting to give me the willies. The other reason I'm growing increasingly concerned is the number of posts in -questions, et al that go something like; "I see in UPDATING that I should be using mergemaster, but I tried it and I don't really understand what the hell it does, so I just didn't bother." I tried to make the man page as simple as possible, and include stuff that I wish was present in other man pages, but it's not uncommon for people to not even bother reading the man page, or read it, get overwhelmed by the options, give up, and go anyway. All of that is background to aid in understanding where I'm coming from when I talk about the following. There are a couple of categories of proposed changes. Some are things that I'm definitely going to do. Some are things that I plan to do, and am currently working on and/or have patches for. I'm including those two categories because if I don't someone will feel the need to suggest them. :) The final category are things that I would like comments about, hence the subject of this e-mail. First, the things I am definitely going to do. Christian "naddy" Weisgerber has taken on the task of porting mm to openbsd. He has made some very reasonable requests that will make his life easier and reduce gratuitous differences between versions. Also, several people have asked for the ability to specify DESTDIR, which is an easy fix and definitely an understandable request. Second, the things I am planning to do. Several people have asked for mergemaster to make use of cvs, going all the way back to freebsdcon. However, it's only been recently that anyone has given me actual concrete plans on things
passwd.1
I don't know who to contact about this, so I'm hoping some people subscribed to this list have commit access. I found some spelling errors in passwd(1) manpage. I have RELENG_4 installed. Here's the output of diff -u: --- /usr/src/usr.bin/passwd/passwd.1Wed Mar 1 04:20:07 2000 +++ passwd.1Sat Sep 16 22:33:16 2000 @@ -78,7 +78,7 @@ .if n "mixpasswordcase" setting for a user's login class). Allowing lower case passwords may be useful where the password file will be used in situations where only -lower case passwords are permissable, such as when using Samba to +lower case passwords are permissible, such as when using Samba to authenticate Windows clients. In all other situations, numbers, upper case letters and meta characters are encouraged. .Pp @@ -186,7 +186,7 @@ an NIS server to also be a client) in which case the .Nm passwd command needs to be told what domain to operate on. -.It Fl s Ar host +.It Fl h Ar host Specify the name of an NIS server. This option, in conjunction with the @@ -202,8 +202,8 @@ be .if t ``localhost''. .if n "localhost". -This can be overidden with the -.Fl s +This can be overridden with the +.Fl h flag. The specified hostname need not be the name of an NIS master: the name of the NIS master for a given map can be determined by querying any If I'm composing to the wrong list, please let me know who I should contact about errors like this. Peter Avalos TheShell.com -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/ED/B d-(+) s:+> a-- C++$ UBLO$ P+ L E- W+ N+ o? K? w(++) !O M- V- PS+ PE++ Y+ PGP++ t+@ 5 X- R- tv+ b++ DI- D-- G e>+++ h-- r++ y++ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
