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

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

On Sat, Mar 13, 2010 at 08:02:51AM -0500, der Mouse wrote:
 >>> [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.

No, except that it is somewhat useful to be able to identify a device
node (or at least distinguish it from others) and plenty of existing
code expects the st_rdev field to exist. Patching all that is only
worthwhile if it accomplishes some purpose, which it wouldn't really.

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

Yes... and no. There's another sense in which /kern/hostname is the
same as /etc/passwd: both are text files that affect the system
configuration. Changes to both also have immediate operational effects
on the running system. The fact that one is not preserved across
reboots is a negligible difference from the perspective of some
program that might randomly open either.

Unexpectedly opening a tty without being prepared to hang indefinitely
waiting for carrier-detect is a different class of problem. Many
devices also are not like regular files in that you cannot read back
what you write to them; /kern/hostname is again a regular file by that
standard.

I'm not saying that it might not be useful to tag /kern/hostname
somehow (and /etc/passwd too) so that certain classes of programs,
like say mail delivery tools, can categorically refuse to write to
them. But that's kind of a different issue from marking devices...

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

True, but the semantics that can be expected in practice of S_IFCHR
and S_IFBLK are very limited - most (but not all) S_IFCHR objects
won't seek, for example, and S_IFBLK objects generally require aligned
I/O and have a fixed size, but there are few other expectations. Which
is, after all, why we mark devices as devices; they don't necessarily
behave as regular files can reasonably be expected to.

 > > [...], 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.)

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.

One can identify (most) programs that are going to try to interpret
st_rdev the old way by getting rid of the major() and minor() macros.
(IMO, any program that slices up dev_t on its own without using those
deserves the consequences.)

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

They are foreign to the filesystem they're being attached into? Maybe
the choice of words isn't so great, but there's a real difference
involved.

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

But that big array is part of the conceptual entity that the inode
represents. The driver pointed to by a device special file is not part
of anything in the filesystem.

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

No, there is no devfs, there are just specfs vnodes that are mounted
directly in /dev. One could argue that in that case specfs should be
called "devfs", but that misses the point of what "devfs" is supposed
to mean.

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

Well, I have used some too; I wouldn't call the configuration a solved
problem, inasmuch as amd config is at best grotty and the old System V
automounter config was entirely unspeakable.

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

Maybe, but if so what purpose does the devfs serve other than to be
too many levels of indirection?

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

Well yes, but that implies you have an existing name and something
bound to it. If you don't have the name, you don't have the binding
either, and that's the problem...

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

Maybe. Not really convinced... but if so that's a different issue.

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