Re: [9fans] qids

[Axel Belinfante <Axel.Belinfante@cs.utwente.nl>]

Thanks for this remark. I have been wondering about this too.

I still hope to someday reimplement (or have students reimplement)
one of our tools on plan 9, and then `heavily' use overlaying.
The idea would be to have a chain (pipeline?) of tools,
where each of them extends (or modifies?) the file hierarchy
it gets from its predecessor in the chain.
So far, I have mainly been thinking about file servers that
extend the set of files they get, like e.g. starting with
fileserver A, and then have fileserver B which serves the 
iles of A, together with a few files that B adds itself
using information taken from files of A.
Then C would take its files from B, etc.
There would probably be a different kind of fileserver D
that gives a whole new view of the stuff from C,
instead of just adding files to it.

The advantage I would have wrt qids is that (assuming I
`control' all tools in the chain) I would be able to devise
my own conventions to guarantee uniqueness.

It occured to me that this approach looks a bit like passing
(attributed?) (abstract syntax) trees around between
components in a tool chain. The extending file server
then essentially just adds additional attributes to the tree.

I don't expect this approach to be the most efficient one
w.r.t. burning cpu cycles, but it should result in a pretty
flexible tool set, where you `build' a particular tool (instance)
by combining the `right' elements in the tool chain.
To get a slightly different tool, you just replace a component
by one that implements a slightly different algorithm.
Also, it has the (educational) advantage that it makes the
intermediate (tree) data structures visible using ordinary
tools (just look at the file hierarchy and the files served).

Someday I'll really find some time to work on this, someday...

Axel.


> Servers of original
> files are encouraged to use only the low 48 bits of the
> qid.path to permit encapsulating servers to use the top
> 16 bits to generate uniqueness.  The code in exportfs
> may be a good example, but last I looked it was a bit
> obscure.