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

[Kyle Moffett]

On Mar 21, 2005, at 18:20, Jeffrey Hutzelman wrote:
> On Sunday, March 20, 2005 07:52:35 PM -0500 Kyle Moffett 
> <mrmacman_g4@mac.com> wrote:
> This is really a bit naive.  It _might_ be a good model for the
> cache manager, but it's not reasonable to assume it is OK to
> combine connections belonging to arbitrary user processes.

If the two calls are using the same key instance, IE: not only
the same data but the same identifier, then they may be combined.
This seems identical to the current OpenAFS model.

> It also totally ignores the fact that in OpenAFS, some accesses
> are done on behalf of users by background processes, which must
> have control over the credentials used for calls they make.

You still have control over your credentials.  The RxRPC library
in the kernel would search the process' keyring to find a key
which it would use when using connections.  If you want to use
a different set of credentials, just create a new thread, then
create a new, empty thread-keyring.  Once you have that thread,
put the credential for the user-process in the thread-keyring
and make your RPC calls.  When done, terminate the thread. The
same procedure works for processes and process-keyrings.

> It also completely ignores the issue of the axscache, which
> stores cached access rights.  For this to work, the cache
> manager must know to what PAG a process belongs, so in fact,
> you have _not_ eliminated the need for PAG's.

The axscache stores cached access rights, which are applied
based on the identity (credentials) of the process, no?  To get
the identity of the process just search the keyrings with the
standard API for an OpenAFS token.  Take the token it finds,
(The one in the most-local scope) and use it to check access.

> As Derrick points out, this is a chunk of fairly complex,
> mostly platform-independent code that we will sill have to
> maintain for other platforms.  So unless _every_ OS vendor
> does this, _and_ they all interoperate well, it gains us
> nothing but headaches.

I've acknowledged that fact repeatedly, however:

>> 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.
>
> Let's not kid ourselves.  Linux does not provide a kernel ABI.

Well, it's an ABI that is broken incompatibly nearly every
revision.  I think that once the Rx layer in the Linux kernel
has become reasonably well tested, its API is likely to remain
more stable than the overall Linux kernel networking API.

> I would very much like to see multiple interoperable
> implementations of Rx. However, it's a fairly complex protocol
> with a lot of subtle nuances (and more than a few warts), and
> getting there will take a lot of effort.

I completely agree.  It is my opinion that by writing such a
system as part of the Linux kernel it is likely to get many
more eyes looking at it and more potential usage, checking and
verification than if it is developed externally (Although
probably not initially).

One other thing to consider is that a number of other OSen
watch Linux for feature ideas.  If a simple user-space API
comes along for Rx sockets, other OSes may implement it.

> Unless and until the Linux kernel's implementation is quite
> stable and very well-tested, I'll be happy to debug problems,
> but I won't suggest that anyone run it in production.

We still only run OpenAFS 1.2 at my school because we hit too
many problems with 1.3.  Decent integration with the Linux Rx
layer is not likely to occur until OpenAFS 1.5 or later, but
it never hurts to work on long-term goals. :-D

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