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

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

>> [st_dev] does not have to correspond, though, to anything else in
>> the system.
> Not really, no, but it may as well be the same as what's in st_rdev.

If there still is an st_rdev.  I see no particular reason that needs to
be preserved.

> The files in procfs and kernfs are for the most part semantically
> equivalent to real files even when they're virtual or dynamically
> generated.  Devices frequently have other properties.

Disagree.  Writing to real files does not, for example, change the
system hostname or alter a process's registers.

In fact, that sounds a lot like the kind of dangers that inhere in
writing to devices indiscriminately, doesn't it?

>> [...] devfs might even involve creating [...] (S_IFDEV, say)
> I don't see any point at all in renaming S_IFBLK/S_IFCHR.

In terms of the end state achieved, neither do I.  But there can be
value in that programs that haven't been ported are more likely to
misbehave if they see a "name" (by which I mean S_IFCHR and S_IFBLK)
they think they know the semantics of but with different semantics than
if they encounter something they don't recognize.

> [...], and any new device type would have pretty much the same
> semantics anyway.

In some respects.  But lurking under all this has been doing away with
st_rdev, which for some programs is a radical enoguh departure that a
new name is deserved.  (Others won't care, but I suspect most of them
don't go looking at st_mode.)

>>> (1) Attaching a device into devfs and attaching a fs into the fs
>>> namespace are fundamentally the same operation.
>> Only at a very general level, [...] at that level open(,O_CREAT,)
>> also qualifies.  So [does mknod()]
> Those are different in a fairly basic way: they create an object
> within an existing filesystem namespace, as opposed to binding a
> foreign object into the namespace.

I'm not sure I'd call a filesystem a "foreign object".  If that's fair,
then the filesystem namespace is _all_ "foreign object"s, and the
"foreign" adjective no longer really means anything there.

> A traditional device node is also a binding of a foreign object, but
> it does it by creating a proxy object in an existing filesystem.

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.
Alternatively, they're all proxies, and the adjective becomes pretty
much pointless.

> Devfs schemes that don't abolish the proxy tend to get in trouble
> because it's too many layers of indirection.  (This is not the only
> problem, but it's *a* problem.)  Devfs schemes that do abolish the
> proxy eventually discover that the fs part doesn't actually do
> anything besides reimplement mount poorly.

> This leads to a non-devfs architecture where device nodes are mounted
> in /dev.

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.

> The remaining trouble arises because they have to be automounted,

Well, they don't, really, but not automounting them doesn't solve any
of the things devfs-style work is attempting to solve.

> As I pointed out somewhere the other day [...], automounter config is
> a previously unsolved problem.

Not all that unsolved.  I've used at least two automounters, each of
which solved it well enough for their purposes.  Device automounter
config *is* unsolved - in exactly the same way that devfs config is
unsolved.  See below.

> I think that approach is ultimately workable without major problems,
> unlike ~all devfs schemes, but getting it right remains a research
> project.

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.  It would even be just a relatively trivial bit of coding to
make them accept the same config-file syntax.

>> That actually does not follow.  Attempting to look up the name (as
>> opposed to doing something with an existing name) could be what
>> triggers the load.
> But what do you load?

The same thing you would have loaded for the same name in a "touch the
existing name and it autoloads" scheme.

>> Of course, that means that the name exists in some sense, [...].
> If the name exists, it's not clear that there's anything (else)
> either hard or wrong about making it visible to userland...

Well, there may be value in its not appearing in readdir() output.

/~\ 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