[9fans] afid and fd, mapping from user space

[9fans] afid and fd, mapping from user space

[Gorka guardiola]

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.
-- 
- curiosity sKilled the cat

Re: [9fans] afid and fd, mapping from user space

[Russ Cox]

The right solution is to proxy between factotum and the fids manually.
Auth_proxy was intended to be simple, not a black box.

Russ

Re: [9fans] afid and fd, mapping from user space

[Gorka guardiola]

I was just thinking about the more general problem of converting a fid
to a fd and/or backwards
so I could do read and write and let the kernel do the 9P chat for me.
Maybe other programs could benefit from it. The idea comes from the
fact that fauth does the work, but there is no way to recover the fid
after to use it in the attach, which is frustrating.

I am doing the proxy by hand now (still working on it) anyway.

On 7/3/05, Russ Cox <russcox@gmail.com> wrote:
> The right solution is to proxy between factotum and the fids manually.
> Auth_proxy was intended to be simple, not a black box.
>

Re: [9fans] afid and fd, mapping from user space

[rog]

> 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 did something like this for inferno, but couldn't work out what was
the best thing to do about non-idempotent 9p transactions: if the
connection is lost before the reply to such a transaction is received,
what is the correct course of action?  the client can't know whether the
transaction has actually taken place on the server.

examples of such requests:

	create
	wstat (rename)
	write to an append-only file
	any operation on a non-standard filesystem (e.g. writing a ctl file)

problems arising from this kind of thing will be
rare, but all the more insidious when they do actually happen.

in the end, i decided to make such requests yield Rerror("operation possibly failed"),
but i have a niggling feeling that the whole approach is wrong.

thoughts?

Re: [9fans] afid and fd, mapping from user space

[Russ Cox]

As long as you don't use it for such things (i.e. use it for a real file
system and don't depend on atomic stuff like locks)
I don't see a problem.  I used it in 3e for quite a while and never
had any problems.  I had to use special bindings to make sure
I didn't try to deliver mail over it, but other than that it was great.

Russ


On 7/6/05, rog@vitanuova.com <rog@vitanuova.com> wrote:
> > 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 did something like this for inferno, but couldn't work out what was
> the best thing to do about non-idempotent 9p transactions: if the
> connection is lost before the reply to such a transaction is received,
> what is the correct course of action?  the client can't know whether the
> transaction has actually taken place on the server.
> 
> examples of such requests:
> 
>         create
>         wstat (rename)
>         write to an append-only file
>         any operation on a non-standard filesystem (e.g. writing a ctl file)
> 
> problems arising from this kind of thing will be
> rare, but all the more insidious when they do actually happen.
> 
> in the end, i decided to make such requests yield Rerror("operation possibly failed"),
> but i have a niggling feeling that the whole approach is wrong.
> 
> thoughts?
> 
>