[Labeled-nfs] Pipes vs Netlink

[Peter Staubach]

David P. Quigley wrote:
> 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.

Not to muddy the waters, but aren't you going to end up needing
rpc_pipefs anyway, just in order to be able to run NFSv4?

It seems to me that rpc_pipefs is the right choice because it
is there already and matches the architecture of the implementation.

    Thanx...

       ps