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/