First, a note - I asked a Linux person I work with why the penguins switched from devfs to udevd. He said that it was a question of pulling relatively complex policy issues out of the kernel into userland, the stance being that things like "users in group pix should be able to access any USB scanner or camera devices that may appear" do not belong in the kernel. I'm sure this forms an argument of some sort for NetBSD's purposes, but I'm not sure which way.
bqt wrote, of devfs and persistent state, > So, what we have basically done, at that point, is to reimplement > what we already have, but in a more complex way. > [...] > Nah, I don't see any gains. Only losses. The current entries in > /dev is working better than this, in combination with MAKEDEV, [...] For your use cases, yes, perhaps. My use cases too, most of them at least. But there are other use cases (some of them reasonable, even :) which the traditional /dev does not support well, such as the "I want the disk with UUID xyz to appear at some fixed place regardless of whether it's on SCSI, USB, firewire, bluetooth, or what" one that's been mentioned upthread. Those use cases, the ones /dev does not handle well, are what are driving devfs. It may be that a devfs is not a good way to handle them. But /dev definitely is not; I don't see much alternative but to keep trying various things until someone finds something better. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
