Messages in this thread | | | Date | Mon, 21 Jun 1999 08:03:13 -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.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/
| |