[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (Semi-random) thoughts on device tree structure and devfs
>> [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
> 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
> 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
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
Main Index |
Thread Index |