[9fans] srv funny?

2009-01-22 Thread Nathaniel W Filardo
I don't undrestand what's going on here:

 term% 9fs sources
 post...
 term% ls -l /n/sources
 d-rwxrwxr-x M 38 9grid  9grid 0 Oct 20  2005 /n/sources/9grid
 ...
 
 term% cpu -h phlogiston.acm.jhu.edu
 cpu% mount -n /mnt/term/srv/sources /n/sources
 
 !Adding key: dom=outside.plan9.bell-labs.com proto=p9sk1
 user[nwf]: 

Why is the terminal able to use /srv/sources to mount /n/sources but the cpu
server isn't able to use exportfs's access to /srv/sources to do the same?

If it helps, I'm running on 9vx for term% and a real Plan 9 system for
cpu%.  My terminal's 9fs is passing -n to srv, too, just to be clear:
 case sources
  srv -nq tcp!sources.cs.bell-labs.com sources /n/sources

Thanks.
--nwf;


pgp69qqWJnpUX.pgp
Description: PGP signature


Re: [9fans] srv funny?

2009-01-22 Thread Russ Cox
 cpu% mount -n /mnt/term/srv/sources /n/sources

 !Adding key: dom=outside.plan9.bell-labs.com proto=p9sk1
 user[nwf]:

 Why is the terminal able to use /srv/sources to mount /n/sources but the cpu
 server isn't able to use exportfs's access to /srv/sources to do the same?

mount -n doesn't ask for keys,
despite what this transcript looks like.
If you run ps on both systems (in other windows),
I bet you will find that the /factotum -g process
asking for the key is running on your terminal,
not the cpu server.

When the cpu server mounts /mnt/term/srv/sources,
it sends Tread and Twrite requests for /srv/sources
to the exportfs serving /mnt/term.
That's a 9P conversation inside a 9P conversation,
i.e. the payloads of the Tread and Rwrite messages
are themselves 9P messages.

Clumsy fact #1:
After an fd has been mounted, ordinary read and write
system calls are not allowed on it: the kernel owns the
9P connection now.  Not doing this would require serious
effort in the kernel, since user-level reads and writes
would interfere with the kernel's reads and writes.

The obvious implementation of Tread/Twrite in exportfs--
call the read and write system calls on the underlying fd--
can't work for exporting /srv/sources, because the kernel owns
the 9P connection.  Instead, exportfs mounts /srv/sources
onto /mnt/exportfs/1 and then invokes itself recursively to
serve /mnt/exportfs/1 onto a freshly created pipe.  Then it
translates the Tread/Twrite messages for /srv/sources into
read and write system calls on that pipe.

Clumsy fact #2:
9P is really intended for two use cases: either the server
never requires authentication (in which case it replies to
Tauth with an Rerror), or it always does (in which case it
replies to Tauth with Rauth and you authenticate on that fid).
Sources is an attempt to have it both ways: if you don't offer
to authenticate (don't bother sending a Tauth), sources won't
ask you to, but if you do offer, you have to follow through.
In contrast, when you offer to authenticate to, say, the plumber,
it just waves you off.  In hindsight, a better way to do the
dual-mode sources would have been to announce on two
different ports, one with authentication and one without.
But what's done is done.

So...

When cpu's exportfs mounts /srv/sources in order to start
serving /mnt/term/srv/sources, it uses amount(2) (just like mount
does without -n), which offers to authenticate and then causes
the prompt.

The -n flag to srv only affects the mount that srv does,
not future mounts.

The easiest thing to do is pretend this didn't happen and
just mount sources directly from phlogiston.  If that machine
doesn't have network connectivity to sources, you could

  bind /mnt/term/net /net; 9fs sources

Russ