Re: Using any network interface whatsoever
Mike Meyer wrote: In [EMAIL PROTECTED], Daniel Rock [EMAIL PROTECTED] typed: So I doubt that the overwriting of an Ingres database really happened in Solaris, like some other poster described - unless the administrator fiddled with /etc/path_to_inst by hand (you are free to shoot in your own foot). That happened very early in the life of Solaris, in the early 90s. Persistent numbering was added to Solaris in response to this incident (there were probably others as well). This was on a relatively large server, with something like 4 SCSI buses. A drive was added to a previously unused bus, making it appear between two drives that were already in the system. This gave all the drives further on in the probe sequence a device number one higher than they had previously had. It sounds for me as if you (Mike Meyer) are asking for something like 'acpidump -d' or 'pciconf -l -v' output, but translated into a filesystem abstraction -- ie a tree of directories corresponding to different busses containing device files ordered according to the bus slot they are plugged into. This would be something that you can use either in place of the traditional /dev or as an adjunct to it. I believe Solaris has a /devices tree which does essentially this. In practice however on the systems we deploy we know that the principal network interfaces are the ones on-board the motherboard, and we know that em0 or bge0 is the one closest to the PSU. Similarly for other devices -- disk device numbers can be deduced from the physical slot they are in. Sure it's just a convention, and it helps that the equipment supplier we use is very consistent about such things, and that in general we don't go around plugging USB disk devices into server systems that frequently. But on the whole it works. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Using any network interface whatsoever
Mike, Tell me about it, I know exactly what you mean! On Sat, Apr 08, 2006 at 06:53:11PM -0400, Mike Meyer wrote: My question about labels for ethernet devices wasn't meant to be rhetorical. Ethernet device names on Unix are pretty much worthless. They tell you basically nothing about which device you've got. On FreeBSD, different card types have different names, which is better than nothing - but that's about all it's better than. We need something akin to labels for ethernet devices. The LAN it's plugged into is the equivalent of the data on the disk - but there's no equivalent for the label. What do I want for that? I identify ethernet boards by which slot on the back of the system I plug the cable into. Currently, I have to map that to board types to and which board is plugged into which slot to know which name to use. I want a name that tells me which slot I plug a cable in to plug it into that interface. I investigated this problem when doing research on XORP. The behaviour you describe is a functional requirement for a router chassis. What it really comes down to is that one needs a PCI variant which supports what's known as 'geographical addressing', and for FreeBSD's device / ifnet framework to support naming cards according to the geographic i.e. physical address. If you look at the very bottom of the man page pci(9) you'll see I've left a footnote about this. Unfortunately the only systems which tend to implement this feature at the moment are CompactPCI based chassis systems. Although there is support for geographical addressing in a recent ACPI spec but as far as I know it may only really have made its way into blade systems. Hope this helps. Regards, BMS P.S. If etiquette were taken more seriously then society as a whole might function better -- I think of it as part of the 'operating system' of the human spirit! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 05:42:13PM -0600, Scott Long wrote: Ceri Davies wrote: On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_if0=DHCP once for every possible value of if, is there a mechanism to do this already? ifconfig_DEFAULT Well, the real question is why we force the details of driver names onto users. Network and storage drivers are especially guilty of this, but tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri I'll say again, how does having em0, em1, em2, and em3 help me know what is going on with each of those interfaces? Well it doesn't, but there is no way for the OS vendor to determine what you're doing. You're more than able to rename them to dmz0, world0 or whatever in order to reflect their real usage if you like. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpxxaANSPXAI.pgp Description: PGP signature
Re: RFC: Adding a ``user'' mount option
On 08.04.2006, at 5:04, Jeremy Baggs wrote: I suppose it would be nice to have something that works out of the box, but the solution I have been using is group permissions on the devices and then making the mount point in fstab relative instead of absolute. ie: /dev/cd0 cdrom cd9660 ro,noauto 0 0 Each user has a cdrom directory under their home directory. You still need mount points designated for all possible devices though. Does anyone know how Darwin / OsX are handling their auto-mount magic? There is a /Volumes folder, and each time user inserts usb flash or cd, the directory is created in that folder, named after a volume label, and mounts the media into newly created directory. Looks like the ``diskarbitrationd'' process is responsible for this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
eth0 works well for the degenerate case where there's a network card in the system, and nothing else. It works less well for systmes where there are more than one card, and where the hardware changes a lot for all the reasons discussed in this thread. It is too generic. Of course, when you have N copies of the same card on FreeBSD, it is as degenerate as ethN is. You can use devd right now to tie the device instance to a configuration using bus topology. That information is available to the devd script that's forked. However, experiments in doing that work only so long as chaning one card doesn't change the hardware topology of the other cards. For single-banger NICs, it won't. However, when you have multi-port NIC cards that are a bunch of individual chips behind a PCI bridge, the PCI bus numbers that they live on change as you insert/remove these multi-port NIC cards, so hardware topology fails you. Then you might think of tying the MAC address to an IP address/configuration. This works well in the above scenario since you can now remove cards that change topology. However, when you replace a defective card with another, you need to reconfigure because the MAC address changes. I've actually run into all of these problems on a machine we have at work that acts as a gateway to about 10-20 private networks. It has had between 2-4 dual cards and 2-4 quad cards, in various mix and match flavors over the years. We've replaced dual fxp cards with quad de cards that were replaced with quad dc cards, etc. Pairs of dual cards were replaced with a quad card at times. We've run a single fxp card in place of a failed quad fxp card for a few days too. The mobo has been replaced a few times as well, which also changes bus topology, as well as introduces new built-in NIC cards. The only solution that works for us has been to carefully desk check the results of each hardware change after the system has been rebooted. After the desk check, a ping of systems ensures that nothing has fallen through the cracks (usually). If there's a way that we can manage this chaotic system better, I'd love to hear about it. Warner P.S. There's conflicting netequite about what I should do with a long thread. some folks say quote the whole thing, others say quote tiny bits. I've decided to offend both camps by quoting nothing :-). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for FreeBSD Status Reports
On Thursday 30 March 2006 02:36, Brad Davis wrote: Hi All, It is time for the quarterly Status Reports. As always, reports are encouraged for anything that relates to FreeBSD development, documentation, independent projects, or anything else that might be interesting to the community as a whole. Reports should be one to two paragraphs in length. The template for submissions is here: http://www.freebsd.org/news/status/report-sample.xml Submissions should be submitted to monthly at FreeBSD.org by April 7th. Unfortunately we have a not too convincing turnout so far. There are - as always - very interesting reports we'd like to publish as soon as possible, but as we have less than half of the reports we had last round we are extending the deadline to Wednesday, April 12th. Please remember that even small progress to you might be worth reporting. Even if you didn't make progress at all it might help to expose your project in the status reports to get feedback to make progress as a consequence of that. Looking forward to your submissions. Thanks a lot. http://www.freebsd.org/cgi/monthly.cgi http://www.freebsd.org/news/status/report-sample.xml -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpWR0YVRrXB3.pgp Description: PGP signature
Re: Using any network interface whatsoever (solution?)
In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: [Tying names to MAC addresses.] That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. If you tie the name to the MAC address, you always have to change that part of the config. If you tie the name to the current name, then you only have to change it if you change drivers. Within the currently available capabilities, we get the network interface equivalent of disk volume labels. Not quite. With volume labels, I can arrange to keep a replicated drive with the same volume label, and can plug it in if the old drive fails without changing a single line of system configuration. Using the MAC address as the key requires that you reconfigure the name mapping (unless you have cards that let you change the MAC address, though I have no idea if those exist for any platform that FreeBSD runs on). [ Proposed use of PCI addresses instead of MAC addresses. ] The real problem with what I proposed is that you have to arrange to search config information for things that may not be tied to a pci bus. That could get real messy. Right, it doesn't scale to ISA or USB devices. The prior probably isn't a big deal these days, but I imagine compatibility with USB devices is fairly important. From what Warner Losh posted (thanks for some hard data, Warner), the PCI address isn't fixed, though you're less likely to run into it moving. And Bruce Simpson (thanks Bruce) tells us that the solution I want - names based on slot addresses - is only available on some hardware, at least for now. There's no reason we can't extend your basic solution to handle configuration by either driver/number or MAC address, allowing the user to pick the properties they want for their names. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. BTW, I'd like to point out that sound cards have the same problem, only they all get the same driver name. Worse yet, the numbering can change between reboots (at least, it could on 4.x). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
On Sun, 2006-Apr-09 09:58:19 -0600, M. Warner Losh wrote: I've actually run into all of these problems on a machine we have at work that acts as a gateway to about 10-20 private networks. It has had between 2-4 dual cards and 2-4 quad cards, in various mix and match flavors over the years. We have several machines (for redundancy) that act as gateways into over 40 private networks. When there were only 4 networks, we used multiple NICs but decided this approach wasn't expandable and we now use VLAN trunks and break out the different networks within the switches. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Using any network interface whatsoever
From: Mike Meyer In [EMAIL PROTECTED], Scott Long [EMAIL PROTECTED] typed: Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0 That's a ridiculous extreme. All I advocated was that we be able to easily identify the devices connected to the system, *not* that we be able identify every device in the world. Sun solved disk device naming back in the 80s. I think this is a problem consisting of multiple parts: 1. Identify physical devices and be able to access them. 2. Identify some stable logical names by device type, that stay fixed when the configuration changes. 3. Be able to find the mapping easily between these two. 4. Be able to change that mapping. USB is probably the subsystem that has a particular need in this kind of stuff. So, since we have devfs nowadays, why don't we just have multiple names (dev files) for the same device? For example, the same device can be named by driver aha0b0t0d0 and by logical type disk0. The 3rd part can be solved by using symlinks in devfs: i.e. disk0 would be a symlink to aha0b0t0d0, and you can do ls and find out what is linked to what. The 4th part can be solved by allowing the sysadmin to create symlinks in devfs. The network driver subsystem would obviously have to be changed to consult devfs for the device names. The next interesting question is how to keep these links persistent between boots. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
Mike Meyer wrote: In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. It wouldn't be too difficult to extend the configuration to allow entries like this: Interface0_addr=MAC 01:23:45:67:89:ab Interface1_addr=PCI 0:1:2 # pci0, device 1, function 2 Interface2_addr=USB 0:1:2 # usb0, addr 1, port 2 Add some bits to grok dmesg or pciconf/usbdevs or maybe even trigger from devd and there you go. I should mention that the second and third options could be broken by the addition or removal of a card with a PCI bridge or USB root hub on it. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. # ifconfig `ifconfig -l link` name GenericName ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Using any network interface whatsoever (solution?)
From: Mike Meyer In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: That's far better than trying to remember what's on em0. That's certainly true. But is there an advantage to tieing the PublicLAN name to a MAC address as opposed to em0? You could test two different drivers on the same hardware and you wouldn't have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. If you tie the name to the MAC address, you always Nope, there is more than one goal. Sometimes you want to tie the device name to the slot, so that you can change the cards seamlessly. Sometimes you want to tie the device name to the card, so that you can move the card around between the slots (this is especially true for USB where you can change the topology very easily). I think the better solution is to let the administrator decide which particular way of tying the names he wants to use for a particular card. (And maybe make some reasonable guess by default, maybe depending on the device type). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
What's in a (device) name?
In [EMAIL PROTECTED], Sergey Babkin [EMAIL PROTECTED] typed: I think this is a problem consisting of multiple parts: 1. Identify physical devices and be able to access them. 2. Identify some stable logical names by device type, that stay fixed when the configuration changes. 3. Be able to find the mapping easily between these two. 4. Be able to change that mapping. I think you're looking at only two of the three aspects of the naming problem. This covers dealing with systems administration, but not using the system. Solving that for a particular device type might make the logical name unneeded. Then again, it might not. So, since we have devfs nowadays, why don't we just have multiple names (dev files) for the same device? For example, the same device can be named by driver aha0b0t0d0 and by logical type disk0. The 3rd part can be solved by using symlinks in devfs: i.e. disk0 would be a symlink to aha0b0t0d0, and you can do ls and find out what is linked to what. The 4th part can be solved by allowing the sysadmin to create symlinks in devfs. The network driver subsystem would obviously have to be changed to consult devfs for the device names. This is essentially the solution that Sun adapted for Solaris. Note that the mapping from logical names to physical names needs to be fixed, so that you might have a system with disk1 and disk2, but no disk0 because it's been removed. The major problem with it is that todays bus architectures don't have stable device addresses. Instead of devices having a fixed address on the bus that the user sets, the addresses are assigned as the devices are discovered. This is pretty much a requirement if you want to sell hardware to 12:00 flashers. While that's not the market that FreeBSD deals with, it is the hardware that FreeBSD runs on. The other problem is that not all devices that need names have entries in /dev. While that's fixable, different solutions will be optimal for different kinds of devices anyway, so we may not want to fix it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
UFS extended attributes
Hi, Started doing a little reading on the UFS and UFS2 file systems. I'm just wondering if all types of files have extended attribute blocks available including named pipes, sockets, and device files? Is it still the case that there are three unused extended attribute blocks available? Sincerely, Duane Whitty -- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : What it really comes down to is that one needs a PCI variant which supports : what's known as 'geographical addressing', and for FreeBSD's device / ifnet : framework to support naming cards according to the geographic i.e. physical : address. I though thtis was already supported. We export bus/slot/function information devd, which can be used to configure the device. : Unfortunately the only systems which tend to implement this feature at : the moment are CompactPCI based chassis systems. Although there is support : for geographical addressing in a recent ACPI spec but as far as I know : it may only really have made its way into blade systems. How is this different than bus/slot/function? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : Of course, this doesn't help the OP's problem of wanting to be able to : address the sole interface in a system without knowing it's name in : advance. Maybe a feature to provide a default name for an interface if : one isn't found in the config file would do that. ifconfig_DEFAULT already handles that. If you have only one interface, it will use the default, no matter which interface you install. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : Mike Meyer wrote: : In [EMAIL PROTECTED], Darren Pilgrim [EMAIL PROTECTED] typed: : You could test two different drivers on the same hardware and you wouldn't : have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: : : Yup, and this is an advantage. On the other hand, if you tie the : device name to the slot number (the real goal), you can swap different : hardware into that slot without having to modify any configuration : information at all. : : It wouldn't be too difficult to extend the configuration to allow entries : like this: : : Interface0_addr=MAC 01:23:45:67:89:ab : Interface1_addr=PCI 0:1:2 # pci0, device 1, function 2 : Interface2_addr=USB 0:1:2 # usb0, addr 1, port 2 : : Add some bits to grok dmesg or pciconf/usbdevs or maybe even trigger from : devd and there you go. : : I should mention that the second and third options could be broken by the : addition or removal of a card with a PCI bridge or USB root hub on it. The device subsystem already exports a bus-dependent plug and play position. No need to make it specific to USB/PCI/whatever. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's in a (device) name?
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : The major problem with it is that todays bus architectures don't have : stable device addresses. Instead of devices having a fixed address on : the bus that the user sets, the addresses are assigned as the devices : are discovered. This is pretty much a requirement if you want to sell : hardware to 12:00 flashers. While that's not the market that FreeBSD : deals with, it is the hardware that FreeBSD runs on. usb assigns addresses dynamically. Everyone else does it basically statically. PCI slot/device numbers are static, but extreme configurations can change the bus number. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
M. Warner Losh wrote: The device subsystem already exports a bus-dependent plug and play position. No need to make it specific to USB/PCI/whatever. Where is this information found? I can't find anything obvious that wouldn't change if you inserted a bus in the middle of the probe order. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using any network interface whatsoever (solution?)
In message: [EMAIL PROTECTED]
Darren Pilgrim [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: The device subsystem already exports a bus-dependent plug and play
: position. No need to make it specific to USB/PCI/whatever.
:
: Where is this information found? I can't find anything obvious that
: wouldn't change if you inserted a bus in the middle of the probe order.
I was replying to the position stuff that was proposed as a way to
find something. I was saying that you don't need to invent special
locators, since all busses are required to provide them.
For example:
% devinfo -v | grep fxp0
fxp0 pnpinfo vendor=0x8086 device=0x103d subvendor=0x104d
subdevice=0x8140 class=0x02 at slot=8 function=0 handle=\_SB_.PCI0.PCIB.LANC
You'd write the devd rule like:
attach 10 {
match slot 8;
match function 0;
action configure-network $device-name;
};
This is technically independent of the bus, since the bus isn't
exported (it should be). I'm told that some machines have multiple
pci domains, so bus number isn't unique. devinfo(8) should provide a
way to get this information as well, but it currently makes that kinda
hard (you could parse out the parent device name).
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's in a (device) name?
In [EMAIL PROTECTED], M. Warner Losh [EMAIL PROTECTED] typed: In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : The major problem with it is that todays bus architectures don't have : stable device addresses. Instead of devices having a fixed address on : the bus that the user sets, the addresses are assigned as the devices : are discovered. This is pretty much a requirement if you want to sell : hardware to 12:00 flashers. While that's not the market that FreeBSD : deals with, it is the hardware that FreeBSD runs on. usb assigns addresses dynamically. Everyone else does it basically statically. PCI slot/device numbers are static, but extreme configurations can change the bus number. USB is popular enough and PCI changes enough that we have to be able to deal with them. Firewire would seem to be a lot like USB - hot pluggable and chainable, though I'm not sure if something like a firewire hub. What does it to do wire down device addresses? Thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
