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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

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

> 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.  (And, if it's
autoloaded, the driver itself may very well be in the filesystem.
Depending on what the driver does, the object, if any, backing it also
may be; consider vnd(4).)

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

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

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.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B