[9fans] an idea

[rog@vitanuova.com]

ok, this idea's a bit off the wall, but i thought i'd mention it
because i think it's got some potential.

some observations on the way 9p works currently:

1) if i import a remote namespace containing /srv, mounting a file in
/srv triples the latency of requests on the mounted namespace (write
tmsg, reply, read rmsg header, reply, read rmsg body, reply).

2) without re-mounting the connection, there's no way of introducing a
new user to a remotely imported namespace.

3) the '#' namespace is quite restrictive (devices can't be attached by
a remote machine, unless using an additional protocol, such as
import), but also overly permissive (there's no way of arbitrarily
restricting the set of devices available to sub-processes)

4) there's an arbitrary distinction between the '#' namespace and normal
namespace, when kernel/user boundary is potentially largely arbitrary.
you can't, for instance, substitute a user-level simulation of device
x if a program accesses it via #x rather than a previously mounted
instance of it.

5) there's a global idea of "user" (the user id of the current
process, as used by fauth(2) at al) but in a situation with resources
imported from many authentication domains, this isn't necessarily
realistic.

6) kernel level devices are privileged in that they can access some
user resources directly, in particular open fds and names.  user level
servers can't.

here's the germ of a solution: put auth files in the namespace.

here's how it might work:

in your namespace you find a file with the DMAUTH bit set, an auth
file.  opening this produces a fid suitable for authentication, which
can also be used as part of a later attach message, giving access to a
new namespace - the namespace accessible as a result of this attach is
distinct (files occupy a different qid space) but derived (the server
decides what namespace to provide from the auth file used).

imagine that /srv contains a load of these auth files.  each one is
like a gateway into a new namespace, in just the same way that the
files in the current /srv are, except that the mount driver's job has
already been done, so that someone mounting one of these remotely does
not incur any additional latency over the network.

moreover (and this is where things start to become interesting, i
think), there's no particular reason why the auth files in /srv have
to be 9p servers - they could be devices too.

suppose, for the sake of argument, that it is possible to have a file
descriptor that represents a walked-to-but-not-yet-open file (the
kernel can do this already; an implementation would be trivial).
suppose also that there are some of the usual 9p-like operations on
such a file, such as walk, bind, open, etc.

then imagine a device similar to the current /srv, except that any
attach gives a new, clean instance, containing nothing at all, rather
than globally shared resources, as currently.  any file descriptor
could be posted to this directory; a walk to it would give you back
the original.

when you boot the system, you bootstrap an instance of the /srv
device, containing an auth file for each device compiled into the
kernel, including the srv device itself.

suddenly you don't need the '#' namespace any more.

to do the equivalent of newns, attach to a new instance of the srv
device, place within it the resources you want available after the
newns (could include auth files, directories, etc), clear the
namespace, and then bind the new instance of /srv (you'll still have
its file descriptor around) onto /.

for a subprocess, you can arrange exactly the set of devices that are
available.  there's also the potential to "push" an authentication
scheme onto an auth file.  in fact there are bucketloads of
possibilities i haven't begun to think about yet.

this kind of arrangement seems to me to make the namespace less
arbitrary and more powerful.  an auth file acts as a kind of tunnel to
another namespace, but one that itself exists within the namespace,
and is thus amenable to "meta-" namespace tools, such as iostats, cfs,
etc.

the implementation would be straightforward (main kernel change would
be having a Dev* inside a Chan rather than indirecting through
devtab), and it doesn't change 9p.  almost all user-level code would
be unaffected.

quite a number of solutions to previously unpleasant problems seem to
me to fall out from this, but i'm likely missing some blindingly
obvious objection.

what do you think?