From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <C9C19233.4D3B50B5@mail.gmail.com>
From: Russ Cox <russcox@gmail.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] an idea
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <499f328d8dc6462edbadb7e4894feaf8@vitanuova.com>
Date: Mon, 26 Apr 2004 11:12:30 -0400
Topicbox-Message-UUID: 6dc364b2-eacd-11e9-9e20-41e7f4b1d025

Here's an independent but seemingly similar idea.

Suppose the kernel were a good 9P multiplexor instead
of a cleaner Unix kernel with devmnt hanging on the side.
All the devices would speak in terms of 9P messages (something
like Fcall or lib9p's Req, not the wire representation).  The
traditional system calls open, read, write, etc. would simply
translate into the obvious 9P transactions, always.  Devmnt's
job then is only to read/write messages from fds.

With 9P messages at the center, exportfs is trivial -- the kernel
would need to rewrite tags and fids in the messages on
their way to the appropriate 9P server.  Suppose also that the
kernel was smart about mounting a channel it exports, noticing
this case and avoiding the extra packs and unpacks to and
from wire representation.  Then fd = exportfs("/a"); mount(fd, "/b", MREPL);
would be equivalent to bind("/a", "/b", MREPL) as far as message
efficiency is concerned -- in neither case would accesses to /b be
any different (in terms of extra wire traffic over pipes) than 
access to /a. 

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.
Then there's no difference between mounting a fd somewhere
and opening that same fd and doing your own 9P traffic on it
via read and write.  (You can't do that right now because once
a fd gets mounted, r/w from user-space would not get multiplexed
properly.)

Now the # names can go away too -- the kernel just starts
by posting all its devices in /srv.  

Of course, this says nothing about auth files, much less authentication.

I think that your scheme uses auth files the same way mine does
9P services.  Put another way, I think (and I could be way off base
here) that your scheme posts unauthenticated 9P services while
mine posts preauthenticated 9P services.

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);.
It might be that on the local machine people are already authenticated
"enough", but I don't see what to do to serve incoming network
connections.

I think some of the things you brought up are independent of
either scheme.  For example, having a file descriptor represent
an unopened file and bootstrapping newns by setting up a name
space in a subtree and binding onto / could be done now without
any significant kernel changes.

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.

I do think there's a germ of a good idea here, but the devil
is in the details.

Russ