>> I really don't like the idea of a devfs.  [...]
> On the other hand, I would say a devfs is not worthwhile as long as
> you still have major numbers and cdevsw/bdevsw... because then it
> doesn't really serve any purpose, [...]

The major benefit of devfs - at least the one that I've seen bandied
about here recently - is that it allows you to refer to things like
"the disk at scsi target 4 lun 2" in a way that doesn't require

	- giving up the sd0, sd1, etc, style of naming
	- having to grovel dmesg output (or moral equivalent) to find
	   out which sdN it is
	- any sort of human intervention to make it continue to work
	   after mucking with the scsi chain
	- enormous (sparse) tables, a la
	   "sd471 at scsibus3 target 10 lun 7"
	   and the hundreds of similar config lines that you'd have to
	   use to "wire down" things to this extent at present.

Even if the leaves are still ordinary block or character device nodes,
this benefit still accrues.

The major problem I see with devfs is lack of permanent permissions on
the nodes.  My preferred solution to that is to provide a way to have a
symlink whose ownership and mode bits are saved and applied to the
targeted object, so that thus-marked symlinks can be used to provide
such things.  (The nodes in devfs might even be mode 000 - root will be
able to access 'em anyway; remember, this filesystem will be local.)

I wonder if the latter problem might not be better addressed with a
filesystem layer (a little like umapfs) that allows such things to be
layered in front of anything.  Such a facility obviously has severe
security implications, so it might best be isolated in a module of its
own where it can be thought about and scrutinized independently.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B