Thomas Cameron wrote: > No, *you* are not getting the point. The old devfs Just Worked(TM) for the > vast majority of us. Hmm. Neither Fedora nor Red Hat ever enabled devfs by default. Who is "the vast majority of us"? > There are *lots* of people on this list who are > reporting problems with udev. I am not one so I can't say what is broken. > But I see that for many, many users udev is problematic. I am not saying > udev is bad. I imagine that once it gets the bugs worked out, it will > probably be pretty cool. I am just not sure I understand why the old devfs > was bad and udev was created. Again, to make perfectly clear: I don't > think udev is bad, I just don't know why we needed it when devfs seemed to > work fine. Well, there's three options: * devfs * udev * traditional /dev Devfs, I am told, suffers from "internal races", which tends to mean that the kernel either gets confused (*not* good when it comes to, say, hard disk devices) or the kernel hangs. It also allegedly has a number of outstanding bugs that are difficult to fix given devfs' design (or are bugs in the actual design) and is "hairy" code, which means it's a potential source of more ongoing bugs. Udev is mainly in user space: it's cleaner code, and if it does crash, the worst that can happen is a device node doesn't get created. Yes, that is better than having the kernel crash. You're tending to get more and more computers that are running Linux and pushing limits: disks with lots of partitions, each needing a node (the fifteen partition limit on SCSI-like disks is an ongoing problem), computers with *lots* of SCSI-like disks, computers that are used as USB print servers for lots of USB printers, etc. The number of nodes in a static /dev is multiplying fast. But the real problem is the sheer amount of new and different USB, Firewire and other sorts of hardware that's being brought out. Not only does that mean that you're going to have a *huge* /dev with a static /dev, it means that there's *still* a good chance that there'll be new devices that aren't in there. And we're running out of old-style 16 bit device numbers to describe all the devices. Linux is moving to 32 bit device numbers, but that means that the nodes in /dev will have to be changed. With an old fashioned static /dev, you presumably would need to modify /dev when you loaded a new kernel, and modify it back for an older one. No fun. Udev will do this automatically. And it will guarantee that if there's a driver in the kernel, there'll be a device node. Besides, there was a lot of overhead in managing the device major numbers. (They couldn't be given out to just any project, so projects had to manage with unofficial numbers, which tended to clash. Then if an official number was issued, existing users had to change their device nodes. No fun). It's not that a static /dev was bad. It's just that the kernel developers think that they can do better. James. -- James Wilkinson | You see hairy 12,000-year-old man walk into my office Exeter Devon UK | soon and say to my computer 'Oh dig me out the E-mail address: james | technical inaccuracies found in Star Trek 5'. @westexe.demon.co.uk | -- The megahal program, trained on my quote file.
