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

[Derrick J Brashear]

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.


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

>> It might. But you know my concerns now. Actually, it may get to the
>> point where RxRPC is easy enough for OpenAFS to use that we do it.
>> It's just not (at least in my opinion, which you might think has more
>> weight than it actually does) a foregone conclusion thaat it's the
>> right answer.
>
> 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.

> much of the nitty-gritty of the Linux networking internals (at least
> for future versions)

This may be true.

> and provide a smaller ABI that is less likely
> to break on upgrades.

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.