Unlike Linux where (nearly) all Networkscards are named eth and all Harddisks are named hd.. BSD names every device after it’s device driver. I like this behaviour, because you don’t get unexpected results, if you load the modules in the wrong order.
Unfortunately there are now so many device drivers, that we are running out of letters, and conflicts happen, e.g. ct0 device is either a “WD33C93[ABC] based CBUS SCSI host adapter driver” found in japanese PC98 or a “Cronyx Tau WAN adapter”, a strange hardware from Russia.
Today I found another conflict, ar0 is either an ATA RAID device node or a
“Digi/Arnet device driver” for another strange PPP/HDLC Adapter.
The greatest problem these conflicts cause, man pages have to have unique names. The ct-conflict was resolved by renaming the Cronyx driver to ctau in CURRENT, but the ar problem is difficult as the Arnet driver is unmaintained (== nobody wants to rename it) and the ATA maintainer is a dangerous axe-wearing Dane. I proposed that the ar.4 link is pointing to the Arnet driver on i386 and to the ATA Raid manpage on !i386.
6 thoughts on “Too few letters”
Comments are closed.
I have to admit, I really dislike to BSD naming scheme, since it makes a PITA to e.g. write shell scripts that do something with the ifconfig output in a generic way. Besides that, it is inconsistent compared to other device naming schemes. Or do you have your harddisk’s device file named after your harddisk’s brand?
I too like the naming scheme. It is strange to get worked in but has a certain logic and thats good. AK you are simply wrong when wanting to name your harddisk’s device files after brand names, remind it’s not named after brand it’s named after driver, and all ide hds use the same driver as do all the scsi hds. Of course it is easier to work with eth[0-n] in shellscripts, but look at the hostap driver or the wlan-ng driver in linux (uh-oh) that is inconsistency.
mihi, you are right that my example with the hard disk was bad, but my assertion is still valid (IMHO) when e.g. s/hard disk/sound card/g.
On the other side, an excuse for naming the network devices after the chipsets is that they don’t appear in the /dev device file namespace (which is one of the biggest mistakes in Unix history, IMHO, and obviously done by people who didn’t understand Unix).
Soundcards are indeed an exception. They are all named after the OSS standard, pcm(4) is some kind of “metadriver”, no matter what driver you use.
I always thought that the /dev namespace was one of the core UNIX philosophies “Everything is a file”.
Why do you think this is a big mistake?
arved: no, my criticism is that the ethernet devices don’t show up in /dev at all, but are only accessible via some (more or less) obscure ioctls. That is just un-Unixish (as in the original sense), the same with sockets.
There are examples how to do it better: there exists an extension for Unix V6 and V7 that provides access to ARPANET. Sending a message to another host simply meant opening a certain device file (one major number was reserved for network nodes, while the minor node was the actual node number) and writing to it. Of course, this can’t be done that easily with IPv4 or IPv6. How it could be done today however is how Plan 9 does it, with the /net filesystem.
Err.. ak, you have seen mount_portalfs(8), right? 🙂 There’s *some* work in that direction in FreeBSD, too.
Actually, I seem to remember some talk a couple of years ago about network devices showing up in /dev, as some other operating systems actually do it. If I’m not gravely mistaken, the names of Julian Elischer and Robert Watson were associated with that talk… and maybe Brooks Davis, but I’m not sure at all. Of course, I could be gravely mistaken, too 🙂