[RTEMS Project] #4475: Add NFSv4 client support to libbds

[RTEMS trac]

#4475: Add NFSv4 client support to libbds
-----------------------------+-------------------------
  Reporter:  Chris Johns     |      Owner:  Chris Johns
      Type:  task            |     Status:  assigned
  Priority:  normal          |  Milestone:  6.1
 Component:  network/libbsd  |    Version:  6
  Severity:  normal          |   Keywords:  nfs-v4
Blocked By:                  |   Blocking:
-----------------------------+-------------------------
 Add NFSv4 client support to libbsd. The client support is part of kernel
 and provides support for a range of the NFS protocol version including
 version 4.

 The task is made of the following:

 1. Update the locks and locking to support the lock manager. VFS requires
 this be supported
 1. Add support for the FreeBSD Virtual File System (VFS)
 1. Add the kernel RPC implementation
 1. Add NFS client support

 == VFS

 VFS is built around the FB's file structure and file descriptor structure.
 These need to be supported. The file struct and file descriptor form the
 basis for all `fd` based interactions with the FB kernel code such as
 files, devices and sockets.

 === LibIO and FB `fd`

 The FB `fd` and `file` support clashes with the existing `libio`
 implementations used for things like `socket`, `kqueue` and `select`.  The
 work to port the VFS requires:

 1. `socket`, `kqueue`, `select` support FB `fd` support. This is closer to
 the kernel. No direct `libio` access
 2. Provide an interface to `libio` mapping the `iop` descriptors to FB
 descriptors.

 This approach nests the FB file descriptors inside the `libio` support.
 This is not optimal in terms of some activities but the hot paths in the
 code should not see a significant change in performance. Some paths like
 `open` are not optimal because the RTEMS file system op handlers imply a
 specific implementation that does not match up well with the FB `namei`
 interface. The long term approach is to look at `libio` and the handlers
 and consider allowing closer integration of FB's `fd` support.

 === BIO and Paging

 The `bio` layer is required for VFS. No paging support other than the
 calls needed to have VFS link are provided. No VM paging is need and none
 of that code need be ported.

 === System Calls

 Collect all the `syscall` functionality exported to RTEMS into a single
 place. Currently the calls are spread around the code and this:

 1. Does not centralize the code
 2. Add a lot of code to FB being ported

 == File Descripter Reuse

 The `libio` functionality of cycling across the `fd` range rather than
 reusing lower `fd` numbers is not compatible with the `select` call. Not
 reusing `fd` numbers once closed until the range as been used provides
 some protection against bugs where a user does not cleanly handle the `fd`
 they own however this is not compatible with FB and makes supporting
 `select` harder.

 The `select` interface should not be used on RTEMS and users should be
 encourages to use threads for concurrent IO or `kqueue`. The means
 `select` may exist for legacy code porting reasons however the cycling
 `fd` count reduces how well the code ported will actually work. For
 example port a piece of `select` code, open a socket and use, it may work.
 Then `open` and `close` a file 64 times then run the same code. It will
 fail.

 FB `fd`'s are reused.

 == RPC

 The legacy NFSv2 client the the NFSv4 cannot be built at the same time.

 The kernel RPC and the user land RPC cannot exist in the same build. I
 have not looked extensively into this but I was seeing clashes with
 headers for the same types but different contents. The legacy NFSv2 client
 uses the user land RPC code while the kernel NFSv4 uses the kernel's RPC.

 Module support is already in `libbsd` to handle the separate building of
 each piece.

 == Security

 NFSv4 provides a number of extra security features. The code will be
 ported is possible but little or no security tested is planned at this
 point in time.

 == Testing

 The NFSv4 stack will be tested against Linux and FreeBSD servers.

--
Ticket URL: <http://devel.rtems.org/ticket/4475>
RTEMS Project <http://www.rtems.org/>
RTEMS Project