From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
From: "Russ Cox" <rsc@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011107172819.F21B119A02@mail.cse.psu.edu>
Date: Wed,  7 Nov 2001 12:28:11 -0500
Topicbox-Message-UUID: 18553440-eaca-11e9-9e20-41e7f4b1d025

You're calling a link a map (dir,name)->file.
Fine.  But that's not what the mount table is.
In the kernel, the mount table map is from current file to
replacement file.  If I mount a file server onto /n/emelie,
it is NOT the case that what happens to lookup /n/emelie/sys is
	walk to /n via 9P
	notice /n/emelie in the mount table
	walk to /sys on the emelie connection

What really happens is
	walk to /n/emelie via 9P
	notice /n/emelie in the mount table
	walk to /sys on the emelie connection

If I mount a file server onto /n/emelie and then in
another window remove the /n/emelie directory (in the
other window there's nothing mounted there so it's empty)
then I lose the mount in the first window, because the
link (/n,emelie)->empty directory is provided by
the protocol not the kernel.

The mount table stores no names at all (at least
for the forward direction).   Instead, the qid we get
from walking to the mount point directs whether
a translation happens.  The mount table is a
bunch of file->file mappings.

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.

Russ