Re: [9fans] an idea

[rog@vitanuova.com]

> Now suppose /srv could only post 9P services, meaning that when
> multiple people opened the same service, the kernel would take
> care of multiplexing their 9P requests appropriately so that the
> original poster would only see a single logical 9P conversation.

this, presumably, would mean that the kernel would have to know about
srv files, and translate all reads and writes through them as 9p
messages (after all there's no guarantee that something posted into
/srv, although a 9p service, has been either mounted or exported on
the local machine, and we need to multiplex reads correctly).

ok, so we assume a kernel knows about srv files.

it could know by looking at the device letter, or by a mode bit in the
file.  let's assume the latter, as it's more general (and reducible to
the former).

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.

how can we do that without adding latency?  even if the local kernel
knows that the remote file represents a 9p connection, how can it
actually transfer data to and from that connection?

the 9p messages directed to that connection must be in-band with the
9p messages from the original connection - the only alternative is to
use Twrite and Tread messages, which adds latency.

that implies that all those messages must have valid tags, fids, etc.
but where have those fids come from?

you need something to associate the old fid (open on the file in /srv)
with the new fid (representing the root of the new hierarchy).

i can't see how your scheme can cope with that.

> I don't see how to do authentication in user space and keep the
> "reductions" of things like fd = exportfs("/a"); mount(fd, "/b", MREPL);.

i'm not sure one needs to try.

i think you're maybe glossing over something here too.
one doesn't usually do the above, but actually:

	exportfs(p[0], "/a"); mount(p[1], "/b", MREPL);

where p[0] and p[1] are two ends of a pipe.
presumably the kernel would have to know about the pipe
device as a special case?

> Suppose the kernel were a good 9P multiplexor instead
> of a cleaner Unix kernel with devmnt hanging on the side.

i think what i like least about this scheme is that you need lots of
extra processes...  all of which are unnecessary.

one thing that's really nice about the current kernel scheme is that a
file operation at user level is just a function call in the kernel.
you already have the process context around, and that's what gets used.

if devices speak in terms of 9p messages, you're talking about a
stream of 9p messages.  many processes write messages into the stream,
and then you need many processes at the other side to deal with the
concurrency (as exportfs does).  you're dealing with a many-one-many
mapping, rather than the current simple one-one scheme, not to mention
the additional data copying, context switches and fid/tag counting.

> What I don't really understand about your scheme is how much
> you're getting from an auth file being authentication-related and
> how much you're getting from it being the beginning of a 9P 
> connection.

it's crucial that you can do the authentication, as it allows a
service to multiplex several different users onto the same connection.
as charles likes to point out, the "important" authentication is the
kind that Styx uses - i.e.  end to end.  however, once you've
connected to a party you trust (to some extent) to act on your behalf,
it's still useful to be able to authenticate yourself to third parties
through them.

to some services the identity of the user doesn't matter.  others rely
on it totally (for instance /proc).

i'm not sure exactly what form local authentication should take though.

[you can defer the decision though: suppose that all kernel
level devices believed whatever user was named in the attach message.
then imagine a device which, given an auth fd, produced another
auth fd that required the client to satisfy certain authentication criteria
- once satisfied, an attach would attach to the original device,
as the correct (and authenticated) user. in this way you could push
whatever authentication scheme you liked onto all the kernel devices
available in /srv]