Actually, it is possible to combine a devfs with some sort of
configuration file so that all the changes you list survive across
reboots, but I agree with you that its not clear why you want devfs in
the first place...

der Mouse writes:
> > Another way (which I prefer) is to eliminate MAKEDEV and let the
> > kernel make the device nodes for us, possibly in a special filesystem
> > for that purpose, automatically mounted on /dev/.
> 
> I really really dislike this.
> 
> Why?  Because it means the user-level device names are wired into the
> kernel.  Because it means I can't "ln -s kd ttykd" to fix "ps atkd" on
> the sun3 port as a stopgap measure until ps is fixed right.  Because it
> means I can't "chmod 666 /dev/*sd4*" so that anybody can access the zip
> drive.  Because it means I can't "chgrp backup /dev/rsd*" so that I can
> have a group dedicated to backups to read the disks, instead of having
> to use the provided operator group which owns ghod-only-knows what
> else.
> 
> Or if devfs does support the above, it means the results won't survive
> the next reboot.
> 
> To me as a sysadmin, this is unacceptable.  devfs may be useful,
> perhaps; I'd actually prefer to make it part of kernfs (/kern/dev, say)
> and then if you really want to use it as your /dev, symlink /dev to
> /kern/dev (and create a few things in /kern/dev on the root filesystem,
> to be hidden by the kernfs mount, enough things for it to come up far
> enough to mount kernfs).  Personally, I'd create a database of things
> in devfs I don't want in /dev and things I want in /dev even though
> devfs doesn't have them, then check /dev against devfs and this list at
> boot time, warning of differences but not touching anything.
> 
> 					der Mouse
> 
> 			       mouse@rodents.montreal.qc.ca
> 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B