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

[Jeffrey Hutzelman]

On Sunday, March 20, 2005 07:52:35 PM -0500 Kyle Moffett 
<mrmacman_g4@mac.com> wrote:

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

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

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.



> One of the other advantages of the Linux RxRPC layer, although this

A nit: the name of the protocol is 'Rx', not 'RxRPC'.


> 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

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.



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



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


-- Jeff