From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <599f06db050701152062c908fe@mail.gmail.com>
Date: Fri,  1 Jul 2005 17:20:41 -0500
From: Gorka guardiola <paurea@gmail.com>
To: 9fans@cse.psu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: [9fans] afid and fd, mapping from user space
Topicbox-Message-UUID: 613ae8d4-ead0-11e9-9d60-3106f5b1d025

I am porting Recover to 4e. Recover is a filesystem which speaks
9P with two ends, a server and a client. When a connection falls down
it pushes the state and restarts the pending requests, so you don't
see a hung channel any more if your connection falls down.

I am now working on the authentification part. The problem I have is
that after doing the Tauth, I have to do the authentification RPC's
over the afid. auth_proxy would be just fine, except that it takes a
real file and does not speak 9P. I only have is a fid on a 9P
conversation.

I could use fauth, but then there would be no way to recover the fid
which I need for the attach later. I imagine four solutions for this:

First, which is what I would currently take rewrite auth_proxy to use
9Pread and 9Pwrite
which read and write from a fid using 9P over a connection.

The second would be to take out the system call fauth() which I dont like
and replace it with new one (fauth can be a library function) which
maps an fd with a fid so the kernel does the 9P talking. This may
require more changes for the attach, I don't know.

Third, writing a kernel filesystem, srvlike were you could post a
connection, give it a fid and get a file where you could read from.

Fourth, posting fids for file on /proc/xx/fd, this is the simplest
one, probably, though it requires changes all around.

What do you think about this?. What is the right approach?. Is there a
simpler way of doing this I have not thought of?.
TIA,

G.
--=20
- curiosity sKilled the cat