Messages in this thread | | | Subject | Re: UUIDs (and devfs and major/minor numbers) | Date | Sat, 19 Jun 1999 10:14:09 -0400 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <Pine.LNX.4.05.9906190814310.26257-100000@mhw.ULib.IUPUI.Edu>, "Mark H. Wood" writes: +----- | On Thu, 17 Jun 1999 tytso@mit.edu wrote: | [much useful argument, snipped] | > The issue is not virtual FS versus some other kernel interface. The | > issue is what appears in /dev, and whether the kernel code should be | > hard coding what happears in /dev. It shouldn't. That's policy. The | > kernel shouldn't be dictating policy. | > | > Instead, the kernel should be exporting sufficient information so that a | > user-mode daemon can provide whatever interesting naming scheme (and | > that naming scheme might include device names based on the UUID or the | > fslabel in the ext2 device, or something else far more general than what | > kernel-space code can provide.) | | it works well. The kernel does pick a (simple) structure for names, a | structure that does not please everyone but is at least consistent and | fairly cheap. The kernel also provides a generator function, | SYS$GETDVI(), which will produce one-by-one the names of all the tape | devices, or all the disks on cluster node FOO, etc. It doesn't cover bus +--->8
Someone please explain:
(1) why exporting this information from the kernel in the arguably most useful form --- a virtual filesystem --- is more evil than exporting it as e.g. a /proc file or a generator sysctl();
(2) why devfs detractors all think devfs somehow *has* to be mounted on /dev, when clearly it doesn't (and it's IMHO even more useful when mounted on /devices, with a devfsd / vold to tend to hot-swappable devices).
(And (2a) I'd like to know why hpa asserted that "devfs is only useful if everyone uses it and mounts it on /dev" (paraphrased). Huh? I missed something, apparently.)
At this point I'm pretty sure that the devfs boosters and detractors are arguing past each other and nothing's going to be accomplished until they're both talking about the same thing.
-- 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/
| |