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/