Re: (Semi-random) thoughts on device tree structure and devfs

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Mar 10, 2010 at 10:22:40AM -0500, der Mouse wrote:
 > Everything starts somewhere.  I would never go near Uebayashi-san's
 > devfs in any of the incarnations described so far on a production
 > system.  But I think it's high time someone started thinking about, and
 > experimenting with, alternatives to traditional device nodes and device
 > numbers, and I'm glad to see this happening.

...twelve years ago. http://www.eecs.harvard.edu/syrah/vino/

Apart from the general problems with devfs as a concept (which I've
blathered plenty about in this and other discussions) based on that
experience there are some pertinent things I can say here:

(1) dev_t cannot go away, because a fairly fundamental guarantee in
Unix is that two files are the same if stat returns the same (st_dev,
st_ino) pair for each. Violate this semantic at your own risk.

(2) As Joerg (I think) already noted, it is perfectly sufficient to
just number devices as they're attached. There is no particular need
to give these numberings semantic significance, or make them
persistent across reboot. (Although for nfsd you need to check where
your NFS file handles are coming from.)

(3) It is also necessary that device nodes continue to appear as
device nodes to stat (S_IFBLK, S_IFCHR, etc.) because assorted
regrettable things happen if e.g. disk partitions appear to be regular
files. Given this, by far the path of least resistance is to fill
st_rdev with the same dev_t value already generated.

 > With that in mind, I'd say that the more radical Uebayashi-san's devfs
 > is, the less like past (failed) attempts at devfses it is, the more
 > likely it is to turn out to be a better way.  Eliminating (this use of)
 > dev_t is an example.

As the foregoing implies, VINO's devfs had no dev_t, or at least, no
semantic dev_t. I would still call it a failure; however, building it
did point out at least two important points in addition to the ones
above.

...

oh, why not.

(1) Attaching a device into devfs and attaching a fs into the fs
namespace are fundamentally the same operation.

(2) Trying to support both dynamically loadable drivers and
automatically named device nodes causes chicken-and-egg problems.
(If a driver isn't loaded, it has no name entry, and therefore you
can't cause it to be loaded by touching the name entry...)

-- 
David A. Holland
dholland%netbsd.org@localhost