Re: UUIDs (and devfs and major/minor numbers)
Mark H. Wood (mwood@iupui.edu)
Sat, 19 Jun 1999 10:42:22 -0500 (EST)
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/