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

[Kyle Moffett]

On Mar 20, 2005, at 18:07, Derrick J Brashear wrote:
> On Sun, 20 Mar 2005, Kyle Moffett wrote:
>> To say it simply, aklog doesn't care about your Kerberos ccache, 
>> because
>> that's _only_ an issue for the MIT or Heimdal Kerberos libraries.  
>> Once
>> you get a ticket from the _library_ interface, you can do whatever you
>> want with it.
>
> Yes. But I'm not worried about the aklog part here (and really, my 
> hope is
> we can get to the point where userland helpers can autoget afs tickets 
> for
> you). I'm worried about the kernel. The kernel isn't going to pull in
> complete kerberos libraries, so the format of the cache matters. aklog 
> is
> easy, aklog exists in userland and can do whatever, but it's not what's
> providing the credentials to Rx when Rx needs them, it's just a tool 
> used
> to prime that cache.

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.

>>> The RxRPC layer would keep track of the connections associated
>>> with each process automatically,
>
> What does this mean, though? If I get tokens once, why should running
> 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.

>> The benefits of using the kernel RxRPC layer is that it is far more
>> integrated into the Linux kernel than the AFS RxRPC layer is and
>> provides a more Linux-like interface.  However, I do understand that
>> may not work well for OpenAFS.
>
> 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
much of the nitty-gritty of the Linux networking internals (at least
for future versions) and provide a smaller ABI that is less likely
to break on upgrades.

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