[9fans] remote 9p multiplexing

[Russ Cox <russcox@gmail.com>]

> say we've imported a namespace from a remote machine.  in the
> namespace is a /srv directory, containing various exported 9p
> services.  we wish to mount one of them.

okay, let's return to this.  in my scheme, since the remote kernel
is doing appropriate multiplexing, we don't need to do anything
special to use the remote /srv/foo.  (actually, we the local machine
don't need to do anything special even now, but that's because
exportfs the program is invoking itself recursively behind our back.)

of course, since /srv/foo is treated like a normal file, there is
message encapsulation and the like, which does incur extra
latency.  i never claimed to handle this case.  i didn't realize
you were claiming to handle it.

it seems what's needed to handle it is some way to introduce a
new conversation into an extant 9P connection.  david mazieres
suggested such a thing a few years ago when he interned at 
bell labs.  in his scheme there was (approximately) a Ttunnel/Rtunnel
message that took the place of Topen/Ropen for 9P connections,
and the net effect was that the 9P connection just opened could 
use the original 9P connection for its messages rather than 
encapsulate them in Tread/Rread/Twrite/Rwrite responses.
i never understood the details (i'm not sure anyone did).

i think the crux of your message is that Tauth/Rauth can be coerced
to let us pull this off, because it introduces a separate "attach space".
i'm going to try to paraphrase:

when afd != -1, the fd in mount(fd, afd, where, flags) is redundant.
if you mounted 9P services by opening them, running authentication,
and then calling mount(afd, where, flags), we could adopt the convention
that the 9P connection for the mount is the one where afd is a fid.
then Tauth invents a fid out of thin air to bootstrap a connection,
but if the fid has been gotten by open, mounting this fid can be 
handled without further encapsulation.

now *that* is cool.  the auth fids are really an indirection layer
and Tauth/Rauth just provides a base.  of course, they'd more
properly be called something else, since this has nothing to
do with authentication and everything to do with setting up the
context of a new 9P conversation.  maybe session fids.

that's really neat.  it separates the setup from the actual session
in a nice clean way without the clumsy 9P1 kernel hack and 
without any encapsulation overhead.

sorry about being so dense i didn't get it the first time around.

russ