We have FUSE, could we have NUSE ?

We have FUSE, could we have NUSE ?

[Matti Aarnio]

(somebody should invent a "better" name for this)

We do have a support of file-system engine in userspace process.
Could we have a socket interfaced network protocol engine in userspace ?

I would like to place things like AX.25 service into userspace, but have
application codes to use kernel socket API (and even ABI) as if the service
is in the kernel.

Required bandwidth for many of these protocols is quite small, therefore
having those within the kernel is unnecessary.  (Not to mention that quite
many system integrators choose not to turn them on...)


The aim of "NUSE" from applications point of view would be to be
indistinguishable from kernel implemented services.

What would this require from the service hook side ?
  - Socket read and write can be trivialishly done
    like a pipe in between processes
  - Somehow pass ancilliary data for:
     - socket, socketpair
     - connect, bind
     - accept
     - listen
     - getpeername, getsockname
     - sendto, send
     - recvfrom, revc
     - setsockopt, getsockopt
  - poll / epoll ?

Death of the protocol engine process must also destroy all existing
sockets of the served protocol type, and refuse to generate any new
sockets of the type.


The first protocol that I have in mind to implement on top of this service
does not need very much of local sockets.
(It is called "STANAG-5066" - radio data communication on HF frequencies.
Specification is written by NATO, thus "STANAG", but my use plans for it
are more along the AX.25 ham-radio things.)


/Matti Aarnio

Re: We have FUSE, could we have NUSE ?

[John W. Linville]

On Thu, Mar 08, 2007 at 12:53:20PM +0200, Matti Aarnio wrote:

> The aim of "NUSE" from applications point of view would be to be
> indistinguishable from kernel implemented services.
> 
> What would this require from the service hook side ?
>   - Socket read and write can be trivialishly done
>     like a pipe in between processes
>   - Somehow pass ancilliary data for:
>      - socket, socketpair
>      - connect, bind
>      - accept
>      - listen
>      - getpeername, getsockname
>      - sendto, send
>      - recvfrom, revc
>      - setsockopt, getsockopt
>   - poll / epoll ?

It is certainly possible to do this by implementing your own socket
family.  I did such a thing as infrastructure for talking to network
processors in a former life.  In that case the socket code was talking
to other kernel code, but getting it to coordinate w/ userland is
largely a SMOP.  You might consider using (generic?) netlink for
your backend communications to the userland daemon.  In addition,
there might be other kernel extensions required (e.g. dynamic socket
family allocation?).

> Death of the protocol engine process must also destroy all existing
> sockets of the served protocol type, and refuse to generate any new
> sockets of the type.

That's up to you (or whomever implements the kernel code).

> The first protocol that I have in mind to implement on top of this service
> does not need very much of local sockets.
> (It is called "STANAG-5066" - radio data communication on HF frequencies.
> Specification is written by NATO, thus "STANAG", but my use plans for it
> are more along the AX.25 ham-radio things.)

Nifty. :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: We have FUSE, could we have NUSE ?

[David Miller]

From: Matti Aarnio <matti.aarnio@zmailer.org>
Date: Thu, 8 Mar 2007 12:53:20 +0200

> We do have a support of file-system engine in userspace process.
> Could we have a socket interfaced network protocol engine in userspace ?

People can and have done this using the TUN/TAP device.
There is even an ad-hoc IPSEC implementation with X-AUTH
support implemented in user space using TUN/TAP.