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

Kyle Moffett mrmacman_g4@mac.com
Sun, 20 Mar 2005 17:36:51 -0500


On Mar 20, 2005, at 17:14, Derrick J Brashear wrote:
> On Sun, 20 Mar 2005, Kyle Moffett wrote:
>
>> As far as OpenAFS would be concerned under the new 2.6 kernel RxRPC,
>> the Kerberos implementation used only matters in one program, aklog.
>
> Today. The point was at some point Heimdal and/or MIT will get cred
> cache in keyring support.

Below what you quoted I said this:
> Since it just uses Kerberos library calls to get the
> Kerberos tickets, it doesn't care whether the tickets are in the
> current file-type database, an in-memory database, or the Linux
> kernel's keyring system.

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.

>> The major advantage to integrating with the kernel RxRPC and keyring
>> layers is that it would eliminate the need for PAGs.  The RxRPC layer
>
> Except you're ignoring the part where I asserted you don't need RxRPC
> to use keyrings and hence can get rid of the PAGs without it. So either
> tell me I'm wrong and why, or answer the question I asked.

Under the current OpenAFS code you still need to keep track of the
per-process connection data, which doesn't really belong in a key.  With
the Linux RxRPC layer, that keeps track of it for you. Again, I said 
this
already, but you snipped it.
> The RxRPC layer would keep track of the connections associated with 
> each
> process automatically,

>> The biggest problem that is likely to arise with OpenAFS is that the
>> code-base basically lacks the abstraction to make this easy to patch
>> in.
> Not really. It's trivial to ignore the groups-encoded-PAGs mechanism.

I've not seen this done.  AFAIK, the current OpenAFS code still looks in
2.6 to find a sys_call_table to patch (Even though it doesn't have the
nice symbol to find anymore.  (Please correct me if this has changed).

I am not saying that ignoring the RxRPC layer is at all bad, I just 
want to
make sure that you know about the other options currently in 
development in
Linux.  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.

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