[9fans] local 9p multiplexing

[Russ Cox <russcox@gmail.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).

this is all local.

i just said that srv is now a 9p-service-only tree.
everything posted there *must* serve 9p.
if you post an fd and someone else opens it,
the kernel brokers the 9p messages going across
it so that other people who open it see an independent
conversation while the guy who posted sees a single
conversation in which everything is multiplexed properly.

this requires no extra processes -- a write to a server
side fd goes through to the server and a write to the
client side fd goes through to the client.  it requires
routing during the read/write, but nothing else.

> 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).

the kernel knows whether a file is in /srv because the kernel
serves that tree.  it has to, so that the correct read/write/open/close
etc. routines get called.

> 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.

let's hold off on that.  i said i didn't know how to deal
with networks properly.  thinking about this a little more,
i think i see what you were getting at in your message.
i think what i described and what you described are 
almost completely orthogonal.  i'll expand on your stuff
in a separate message.

> > 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?

only if you think exportfs should be told where to write
if the system call is really fd = exportfs("/a"), there is no pipe.
that's also why there are no extra processes.  in order to
implement /bin/exportfs you'd have to get the export fd
and then ferry bytes between stdin/stdout and the fd.
if you really care you could put a generic trampoline(fd1, fd2)
into the kernel.

> > 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.

there are no extra processes.  all of which are bright purple,
or anything else you like.  there aren't any.

> 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.

this can still be the case.

> 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.

you're ignoring things i said.  inside the kernel there is only some 
data structure representation like Fcall or lib9p's Req.  no need for
copying as the messages move around inside (unless you're worrying
about the cost of copying pointers).  there might be context switches
depending on how you implement things, but they would all be between
kernel processes so they'd be cheap.  fid/tag manipulation is free.

the "other side" can have as many processes as it needs to handle
the concurrency.  the handler for a read from /dev/user could handle
the request immediately.  the handler for a read from /dev/cons might
put it on a queue of pending reads.  in general there's no need for
one-process-per-writer unless you're assuming the devices slip back
into function calls at some point instead of dealing with the 9p
requests directly.

again, remember that this is all local.  i'm not claiming to solve
any problems with doing 9p over 9p or over a network.

> > 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.

i agree with all this.

> [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]

neat.