[OpenAFS-devel] Progress on Linux in-kernel RxRPC library

[Kyle Moffett]

On Mar 20, 2005, at 20:08, Derrick J Brashear wrote:
> On Sun, 20 Mar 2005, Kyle Moffett wrote:
>
>> You wouldn't need to pull Kerberos libraries into the kernel.  If the 
>> AFS
>> stuff needs to prod a user process to get new AFS keys from Kerberos 
>> keys,
>> for whatever reason, just have userspace use a /proc/sys/afs/aklog 
>> file to
>> tell it what program to call, then use call_usermode_helper() to 
>> trigger
>> it and wait for it to do something useful or quit before waking up the
>> original process from its interruptible sleep.  You _still_ don't care
>> what format the Kerberos stuff is in, you only care that _something_
>> understands it enough to give you an OpenAFS token when you want one.
>
> Well, that's not entirely true. The RPC layer needs to be able to 
> choose a
> single credential out of the cache it has.

Fine, so tell call_usermode_helper to set the KEY_ID environment 
variable
before calling the program.

>>> ls and running pine result in different connections to the same
>>> fileserver to use the same tokens to fetch the binaries themselves
>>> and/or to bulkstat?
>>
>> They wouldn't.  The RxRPC library would notice that you used the same
>> credentials for both calls and automatically use the same connection.
>> If it wants to do more simultaneous RxRPC calls than the protocol
>> allows, it would create the extra connections for you when you need
>> them, and close them when you're done.
>
> Ok. Well, we have that now.

Yes, but this was just the continuation of the "get rid of PAGs on 
Linux"
part of the discussion.

>> One of the other advantages of the Linux RxRPC layer, although this
>> is not really noticeable for OpenAFS, is that it is shared code in
>> the kernel repository, which means it's one more complex chunk of
>> code that will be maintained easily by the Linux developers (Which
>> are considerably more in number than OpenAFS developers) that you
>> don't need to worry about on Linux.  It would abstract you away from
>
> But we need to worry about it on the N other platforms, and the amount
> of complexity in it that's Linux specific is basically 0. False 
> economy,
> at least for now.

I agree completely, it's just something to keep in mind.

> It's always inode/filesystem stuff which screws us, and that won't help
> at all. I'd estimate 70% of the pain is there, and much of it could go
> away if we used system inodes. If we could have something for free, 
> that
> would be my first wish.

Does OpenAFS use the cachefs in 2.6, or is cachefs still too immature 
and
missing too many features to be useful?  Also, what does OpenAFS require
for its inodes that Linux doesn't currently provide?

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------