[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          |  Resolution:
 Keywords:  nfs-v4          |  Blocked By:
 Blocking:                  |
----------------------------+--------------------------
Description changed by Chris Johns:

Old description:

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

New description:

 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

 == Proc0

 FreeBSD's initialization creates the initial process called `proc0`. Add
 support to create `proc0` and let all thread' reference it. This allow the
 creds to be managed, kernel trace to work and it removes a number of
 changes that do not need to be made.

 == 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#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project