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 dholl...@netbsd.org