From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <05f311ed4273f9fdadc5f3453a807fed@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] an idea
From: Fco.J.Ballesteros <nemo@lsub.org>
In-Reply-To: <499f328d8dc6462edbadb7e4894feaf8@vitanuova.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Apr 2004 09:57:05 +0200
Topicbox-Message-UUID: 6c237e26-eacd-11e9-9e20-41e7f4b1d025

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

But this could be done by arranging the the final clients to talk to the
actual servers, without resorting to proxy places. But this would require
changing the name space semantics. We do that for Plan B, but don't know
how it would fit with Plan 9. To make it more clear what I mean,
one way to do it would be to make all 9P servers become network addressable,
then change the way the ns is printed so that a user could reproduce the
ns from any other place in the network.

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

A regular  /dev (or whatever) directory with
one mounted file|dir per device would be cleaner. Instead of doing the
#s trick, newns() could return not a clean namespace, but one with
devices installed. To do sandboxing one could unmount from there whatever
is not wanted.

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

This is one thing that I dislike even with the way things work today. But
it would probably require changing many interfaces. The clone interface
is something that I think is confussing.

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

BTW, I don't see why you would need this:

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

Is it to proxy for a remote dev?

PS: I had your mail hanging around since you sent it, it's just that it was not
clear for me how your idea would actually work when compared, for example,
with what I suggested above or with the current behaviour. That's why I
didn't reply earlier. Perhaps the same happen to others.

cheers