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

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

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

This dev_t does not have to correspond, though, to anything else in the
system.

> (3) It is also necessary that device nodes continue to appear as
> device nodes to stat (S_IFBLK, S_IFCHR, etc.)

No, actually.  See below.

> because assorted regrettable things happen if e.g. disk partitions
> appear to be regular files.

Oh, they probably shouldn't appear to be ordinary files.  (I'm not
convinced they can't be; those "regrettable things" could be looked
upon as things needing fixing upon switching paradigms.)  They need
not, however, be traditional character or block device "files".
Indeed, I can't offhand see any reason why userland has to even be able
to tell whether two of them are the same or not (though it can help at
the human level in some cases); as long as opening one connects you to
the correct driver, they could be pretty much anything.  stat()
returning an st_rdev is another of those implementation details that is
not necessary but which people have trouble letting go of because
they're not willing to bite big enough bullets.

procfs and kernfs are examples of filesystems which illustrate that
it's possible to have a non-"device" entities in the filesystem which,
when opened, connect to specialized code.  Doing this with a devfs
might even involve creating a new type of filesystem entity (S_IFDEV,
say), though that's quite possibly not necessary.

> [vino] did point out at least two important points in addition to the
> ones above.

> (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, the level of "new stuff appearing in the
filesystem", but at that level open(,O_CREAT,) also qualifies.  So do
other calls; perhaps most relevantly here, consider mknod() - some of
the ideas mentioned upthread have involved a userland daemon that
actually does use mknod() to create new device nodes.

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

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.

Of course, that means that the name exists in some sense, but that
sense does not have to be one that's visible to userland (while you may
want an administrative interface that lets you see them, it is in no
way essential).

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