Re: UUIDs (and devfs and major/minor numbers)

Mark H. Wood (mwood@IUPUI.Edu)
Mon, 21 Jun 1999 08:03:13 -0500 (EST)

On Sat, 19 Jun 1999, Brandon S. Allbery KF8NH wrote:
> In message <Pine.LNX.4.05.9906191036140.26257-100000@mhw.ULib.IUPUI.Edu>, "Mark
> H. Wood" writes:
> +-----
> | On Sat, 19 Jun 1999, Brandon S. Allbery KF8NH wrote:
> | > 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
> +--->8
>
> But you have to parse any other naming scheme, including a sysctl()-based
> one. And the kernel can't reasonably generate every possible representation
> of the device tree, whether by devfs, SYS$GETDVI(), /proc files, etc.

A query-by-example approach is preparsed, unless you want to invent a
complicated language to pack an example into a string. A vector of tagged
constraint values works better for me. (I wasn't holding SYS$GETDVI() up
as an exact duplicate of what I am talking about -- it could've been
carried a lot farther. IIRC F$GETDVI() actually did. They took away my
VMS system so I can't easily check this.)

Devices are few enough that they can live in a flat namespace, as long as
we can find the ones we want. There's no parsing in a flat namespace,
only enumeration and lookup.

> | 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.
> +--->8
>
> Why wouldn't it be? In its most generalized form, a filesystem is a
> hierarchical database used for kernel-to-userspace communication, which is
> why Plan 9 generalized it to namespaces and why there is e.g. /proc. It
> seems ridiculously narrow to restrict filesystems to handling only real
> "files": where do you draw the line? Network filesystems? Devices
> themselves (shades of DEC OSes)?

I'm not objecting to the filesystem here so much as I am the hierarchy.
The problem is that different people want different hierarchies to solve
different problems. No one hierarchy is general enough to satisfy all, so
I'm asking whether another model *entirely* would be a better fit to the
general problem (that is, the universe of all problems people are wanting
to solve here).

Besides, there's nothing that guarantees a filesystem *must* be
hierarchial. You could have tagging metadata and a QBE filespec syntax if
you really wanted to. (I can't yet imagine wanting to.) Hierarchy wasn't
inherent in the TOPS-10 filesystem, for example; it was grafted in later
because it is, after all, quite useful. Early MSDOS was the same way, I
believe.

-- 
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/