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

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

On Sun, Mar 14, 2010 at 04:43:18PM -0400, der Mouse wrote:
 > >> In some respects.  But lurking under all this has been doing away
 > >> with st_rdev, which [...]
 > > Well, no, we're doing away with a specific interpretation of the
 > > contents of st_rdev. Getting rid of st_rdev itself doesn't serve much
 > > further purpose.
 > 
 > If we do away with device numbers - I think that was mentioned - what
 > point does st_rdev have?  What meaningful values could you put there?
 > The only fundamental purpose they (as used here) serve is to handle the
 > mapping between filesystem entities and driver instances, and that's
 > something that can, and maybe even should, be done differently.

There's one other purpose, which is determining if two device inodes
encountered in the FS namespace refer to the same device or not. This
is not a completely useless property, and if you're going to have some
kind of device identity anyway (as is needed for filling in st_dev)
st_rdev is a natural place to put it for the device node itself.

 > >> I'm not sure how fair it is to call it a "proxy object", any more
 > >> than an S_IFREG inode is a proxy for the big array of bytes (stored
 > >> elsewhere on the disk) that make up the file's contents.
 > > But that big array is part of the conceptual entity that the inode
 > > represents.
 > 
 > And the device driver is part of the conceptual entity that a device
 > inode represents.

No, it's not, because the device inode belongs to a file system and
the driver does not.

 > > The driver pointed to by a device special file is not part of
 > > anything in the filesystem.
 > 
 > Where it is stored is an implementation detail.

Yes, which is why it's not *part* of the filesystem.

 > >> Well, I'm not sure I'd call it "non-devfs", in that you're basically
 > >> creating either one devfs per device or a devfs which exports only
 > >> one device per mount, depending on how much of the device-specific
 > >> part you consider to be part of the "filesystem" that gets mounted.
 > > No, there is no devfs, there are just specfs vnodes that are mounted
 > > directly in /dev.
 > 
 > Depends on exactly what you include under the "devfs" name.  There is
 > no devfs in the sense of something being passed to vfs_attach(), but it
 > seems to me that that, like the existence of vfs_attach() at all, is an
 > implementation detail; there is code (mostly in the automounter) that
 > performs the functions we have been attributing to a devfs, and in that
 > sense there's a devfs.

Sure, but when there's no "fs" it's not really "devfs". It's a way of
handling device nodes, yes. Anyway, this is a pointless quibble.

 > >> I don't see any real difference between an automounter mounting
 > >> devices into /dev individually and a devfs making devices appear
 > >> under a devfs mount.
 > > Maybe, but if so what purpose does the devfs serve other than to be
 > > too many levels of indirection?
 > 
 > I'm not convinced "too many levels of indirection" is fair - and, even
 > if it is, I'm not convinced individual device mounts aren't
 > approximately as bad in that regard.

It is too many (or at least more) levels of indirection:

   root        /dev          specfs        device
   dir   ----  dir    --|--  device  ----  structure
   vnode       vnode         vnode

vs.

   root        /dev
   dir   ----  dir
   vnode       vnode
                 |
              [mount]
                 |
               devfs        devfs        specfs        device
               root  --|--  device  ---- device  ----  structure
               vnode        vnode        vnode

where --|-- is the dynamic attachment (whether variant mount or
something else)

Maybe there doesn't need to be a separate devfs vnode for each device,
but even then there's still one extra indirection.

 > The main purpose it serves, it seems to me, is to collect the relevant
 > code together.  Deciding whether to implement the loose conceptual
 > devfs as individual automounted device nodes or a single devfs mount
 > strikes me as a bit of a toss-up; either can perform the fundamental
 > function of a dynamic mapping between filesystem-namespace strings and
 > device drivers.  I'm perfectly willing to accept your experience that
 > the single-devfs-mount has operational problems, but, pending someone
 > trying it, I don't believe that the other way doesn't.

I've tried both :-)  although the toy kernel I tried the mount form in
didn't have enough devices to make the automounter part interesting,
and that project was far too shoestringy to implement unnecessary
features.

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