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

[Kyle Moffett]

On Mar 21, 2005, at 18:28, Jeffrey Hutzelman wrote:
> On Monday, March 21, 2005 12:20:30 AM -0500 Kyle Moffett 
> <mrmacman_g4@mac.com> wrote:
>> At the moment I'm creating a userspace interface so an RxRPC call 
>> using
>> the  kernel routines is something like this.  The design is still
>> incomplete, so  I'm not sure about the exact appropriate usage of the
>> sendmsg/recvmsg/readv/writev calls or the proper method to pack the 
>> data
>> and ancillary info in the msghdr.  I am interested in your feedback 
>> and
>> if  you think this is a viable method to interface RxRPC from 
>> userspace
>> to kernelspace.
>
> I read this message all of 10 minutes ago, so I haven't had a chance to
> look at it in much detail.  It looks like you're basically on the right
> track, though.  I have to think a bit about what metadata needs to be
> exposed; the fileserver, in particular, does a lot of tracking of
> connections and peers.

Each call socket will provide appropriate address:port information in 
the
same sockaddr_in structure using the same syscalls as are currently used
for UDP.  The fileserver should be able to manage peers in user space
without a lot of work because each one will have a different 
address:port
combo that it can lookup in a hash-table of some sort.  The kernel will
also automatically manage the Rx timeouts for you, settable through a
couple extra (get|set)sockopt options.

> I'm not sure whether every security mechanism will be able to deal with
> the server having to pass in a fixed blob at startup -- the current
> rxkad API involves the server passing in a callback, but it generally
> doesn't actually do much work (it looks up a key in a file, normally).

The security bit in that was just some random brainstorming.  I haven't
actually written any code for that bit yet.  If you have any better 
ideas,
I'd be glad to hear them.  I'd prefer using keys via lookup in the Linux
keyring system, although that won't work for other platforms, on Linux
it's a cleaner API.

> This is definitely the right model.

That's a great thing to hear.  Hopefully if done right I can make a
compat library for older programs that emulates the older userspace
function calls with the newer socket-based API.

One other advantage to using the Linux kernel Rx layer is that it will
use the kernel acrpyto, which provides support for hardware crypto
devices, so servers would be able to save CPU time for other processes.

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