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,

quoted text
> 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		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B