Messages in this thread | | | Date | Sat, 19 Jun 1999 10:42:22 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
On Sat, 19 Jun 1999, Brandon S. Allbery KF8NH wrote: > 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();
You have to parse filesystem paths if you want to understand them. You have to either agree on a one-size-fits-all naming scheme, or use multiple schemes and store duplicate information. You have to develop an intimate relationship between the kernel and a daemon if you want to keep current in the face of hot-plugging, and a number of people think *that* is evil. (I'm undecided on this last point.)
> (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).
Can't help you there since I never said that. I don't consider myself a devfs detractor either; at most I've asked people to consider whether a filesystem hierarchy is really the most appropriate representation for the various information that we all want.
[snip]
> 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.
Nod. Is anyone taking notes on the various orthogonal issues being trumpeted?
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Specializing in unusual perspectives for more than twenty years.
- 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/
| |