[RTEMS Project] #4475: Add NFSv4 client support to libbds
trac at rtems.org
Mon Jul 19 08:57:15 UTC 2021
#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
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 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
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
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
FB `fd`'s are reused.
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
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.
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/>
More information about the bugs