> 
 > >> 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

Ok, I suppose that's true.

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

...and I suppose this is true also. 

 > The major problem I see with devfs is lack of permanent permissions on
 > the nodes.  

this is easy - mount -t devfs /devdat /dev, where /devdat is a small
file used for backing store for this data. You can probably turn
devices on and off this way too and have different devdat files for
your chroot areas and so forth.

 > 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.

We planned (but haven't implemented yet) something like this in VINO.
VINO's device drivers appear basically as arbitrary vinodes(*), and
VINO's devfs doesn't serve much purpose but supporting hanging these
vinodes someplace. In the long run we were planning to merge the
filesystem and device driver mount code, since by the time you have
device drivers looking like this there isn't any meaningful
distinction between drivers and filesystems.

Then you'd be able, at least in theory, to mount devices at arbitrary
points in the filesystem. You can also pass mount options, which is
actually very convenient - for devices where it matters the mode could
easily be a mount option. Other devices automatically know what mode
they ought to be, like /dev/null.

Another approach is to have everything start 0.0 mode 600 and put some
chmods in /etc/rc, but this violates the principle of least surprise
without accomplishing a great deal.


(*) in vino, a "vinode" is what everyone else calls a vnode. don't
blame me, it wasn't my fault.

-- 
   - David A. Holland             | (please continue to send non-list mail to
     dholland@cs.utoronto.ca      | dholland@hcs.harvard.edu. yes, I moved.)