>> [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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
