[Labeled-nfs] Pipes vs Netlink

[David P. Quigley]

Hello,
    I am to the point where I am implementing the user space daemon for
doimapd. At this point I want to get to where the kernel will send
requests up to user space and then the daemon will just take what it has
received and sends it right back. This will give us a good starting
point to work from for when we finally decide exactly how DOI
translation and negotiation are to work. However there is one problem I
have run into. There are several viable methods for this communication
and I have narrowed it down to two choices.

The first option is to stick with the way that idmapd handles this. It
uses a pseudo file system called rpc_pipefs which has a directory for
each NFS client which contains some info and the pipes. I currently have
the kernel code implemented in this way but it can easily be switched
over to the second method if necessary. The benefits to this method are
that we have a good starting point basing the code on idmapd, and most
of it is already implemented for us. The downside is that it forces us
to have a dependency on rpc_pipefs. If the need ever arises to have
Labeled NFS on some sort of embedded device the extra space for
rpc_pipefs might be a problem. However I don't think this will be an
issue for most other situations.

The second option is to use netlink sockets. In this method we remove
the need for rpc_pipefs. The user space daemon would listen on a
particular netlink socket and have the kernel open up a connection to
this socket for each client it starts. In this method the client is
needs to maintain a mapping from a unique client id to the internal data
for that client. The benefits to this is that the user space daemon
implementation will be simpler since we don't need to bother with the
dnotify code that idmapd currently uses. One of the downsides is that
netlink is a connectionless method so we would need to build basic
retransmission into both the kernel and user space code if we want to be
reliable. 

While looking through the kernel documentation I found a protocol class
for netlink which is supposed to be used as a framework for this kind of
thing. The connector family is supposed to remove the need to mess with
sk_bufs and other netlink intricacies. It contains sequence and ACK
numbers in its header so it shouldn't be too hard to implement
retransmission with it.

Any input on this would be appreciated. This is pretty much the only
thing stopping me from moving forward with finishing the DOI mapper
infrastructure.

Dave Quigley