Messages in this thread | | | Subject | Re: UUIDs (and devfs and major/minor numbers) | Date | Fri, 18 Jun 1999 18:17:16 -0400 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <Pine.LNX.4.10.9906181044360.14768-100000@sasami.anime.net>, Dan Hol lis writes: +----- | On Fri, 18 Jun 1999, Alan Cox wrote: | > Thats absolutely identical to the devfs hooks. devfs is generating an fs | > from them, doing a usermode smart /dev is exporting the same data devfs | > builds on into user space and doing the hard thinking in user space. | | So basically devfs might not solve every possible problem at the moment, | but it is certainly the correct infrastructure for solving problems. +--->8
I'm still trying to figure out the "issue" with devfs. What architecture is "better" than it? Perhaps we need to see some code, or at least a decent description of a practical alternative.
In the meantime, here's a thought for the future:
We're all pretty much agreed that device major and minor numbers are something of a problem, especially when it comes to hot-pluggable devices. So what alternatives might there be?
PROPOSAL (for the future; this isn't a 2.3 issue, it might be a 3.0 issue!):
Instead of devfs providing a device tree based on the current major/minor device scheme, it provides a device tree which links directly to the drivers internally. The device's identification, in effect, changes from a major/ minor device number pair to the actual path within devfs. This changes the kernel device namespace to a hierarchical string namespace which is effectively unlimited.
This would not, of course, be mounted on /dev; instead, it would be used the way Solaris uses /devices. As with Solaris, /dev would be populated with symlinks into /devices (or wherever we decide to mount it). Unlike Solaris, /devices would not be a mapping from the OpenBoot device tree to major/minor device numbers, but instead would be the device tree itself.
Advantages:
* no more limiting major/minor number namespace; * the device IDs would be self-descriptive, which major and minor numbers currently aren't (although /proc/devices helps to some extent here); * you could treat components of the device name as flags instead of as devices: this is a conceptually cleaner idea than e.g. treating the normal and no-rewind tape device nodes as if they're separate devices; * the problem with changing device IDs on hot-pluggable USB and FireWire buses doesn't exist. * this devfs isn't policy, it's just a description of all the devices on the system. Policy is set with symlinks in user space, with either a devfsd or a "boot -r"-like mechanism (the latter is easier/faster, but the former is probably necessary for hot-pluggable devices).
Disadvantages:
* you would need to provide a backward-compatibility major/minor number mapping anyway, so devices could be exported over NFS to systems which didn't use this scheme --- not to mention to allow compatibility devices in the filesystem so an extN filesystem can be dual-booted between the new kernel and older device-number-based kernels;
* because it's a strict device tree a' la the Sun OpenBoot device tree, it doesn't itself provide a way to quickly identify all devices of a particular type: this might be solved by exporting /proc-like "files" listing all the devices of particular types, or one might simply iterate over the entire tree to find e.g. all CDROMs.
NB: I'm not convinced that a devfs which is directly mountable on /dev makes sense *in the presence of hot-swappable devices*. It's a bit *too* mutable. "devfsd == vold done right" appears to make more sense IMHO. If there are no hot-swappable devices available, it is workable; but IMHO it's a bad idea to set things up that way because things will go wacky as soon as someone starts hot-swapping USB devices... it's bad to have a default setup which breaks in strange ways when one starts taking advantage of hot-swappable devices on modern computers.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH We are Linux. Resistance is an indication that you missed the point.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |