Re: [9fans] Plan 9

["Thomas Bushnell, BSG" <tb+usenet@becket.net>]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> There are no ``links'' in the mount tables.  None.
> Every (directory,name)->file mapping happens
> by doing a 9P transaction, whether over the wire
> or to a kernel-provided tree.
>
> I still don't understand your proposal, but I think
> a lot of our confusion has to do with this fact:
> there are no links in the kernel mount tables.  None.

Right, I knew this, but I was short-cutting my description in the
hopes of consiceness, and it seems I failed in my attempt.

If there is a mapping from the file FOO to the file BAR specified in
the mount table, then the user will never be able to see FOO, right?

So if there is a directory DIR, and it has a name "foo" which maps to
the file FOO, then the user who looks for DIR/foo will get BAR.
That's the conjunction of a pair of mappings; one is the link in the
directory DIR; the other is the mapping translation from FOO to BAR.

But a user who looks up a file name always and only sees BAR, except
when they use the special tools to manipulate the mount table.  Right?

That situation involves a link from DIR/foo to BAR; the link (a
mapping from a name to a file) is the composition of the in-directory
link DIR/foo -> FOO; and the mount-table mapping FOO -> BAR.

But the second part of that is quite automatic: opening a file always
evaluatios the composed mapping.  It's that composed mapping that I
was (hoping for brevity) calling a link in the mount table.  Yes, it's
actually both in the mount table and in the directory DIR.  But the
point is that if you want to know what looking up DIR/foo gets you,
it's not enough to just look at DIR... you also have to know the
FOO->BAR mapping.

So my idea is that Plan 9 has a great idea: take mount tables and make
them per-process.  From that one very simple idea, a great many
important advantages come.

I'm saying that I think very nice advantages can accrue from saying
"hey, the per-process mount table is a very nice thing: let's make the
entire directory structure per-process, rather than just selected
parts of it."  Now nothing here prevents a clever implementation that
has a default, that allows for careful sharing and efficient lookups.
But at the level of interfaces and what the user sees, this could be,
I think, an improvement.

Obviously, it results in a system very different from both Unix and
Plan 9.  But that's not a stroke against it, is it?