NSFv4: LibBSD VFS and FS

[Chris Johns]

Hello,

Ticket #4475 documents the addition of the FreeBSD NFS client to LibBSD.

https://devel.rtems.org/ticket/4475

The change is large because the NFS client uses FreeBSD's VFS and this in turn
requires LibBSD use FreeBSD's file descriptor and file support. Breaking this
patch down into section that supports bisect would be too much work.

Given the size I have pushed the changes to me personal repo:

https://git.rtems.org/chrisj/rtems-libbsd.git/log/?h=4475-vfs

All branches are presented here.

4475-regen-symbols
------------------

Posted as:
 https://lists.rtems.org/pipermail/devel/2021-July/068571.html

- This change adds a new kernel symbol generation tool that has a consistent
sort across all supported platforms. The script uses the sort command and
FreeBSD and Linux did not agree.

- The namespace kernel header is sorted and committed without addition.

- The namespace kernel header is updated with the everything builtset.

- Building the Versal uncovered clashing function names in WPA and dhcpcd code.

- The new kernel symbol tool exposed duplicate symbols in sys/netinet.

4475-lockmgr-proc0-ktr
----------------------

Posted as:
 https://lists.rtems.org/pipermail/devel/2021-July/068544.html

- Prevent a timer overflow if the timeval is out of range for the platform int.
This change is needed to avoid an indeterminate NFS RPC client connection due to
an invalid timeout value.

-  Add lockmgr support to locks. The VFS and file system code uses the lockmgr
interface to control locks. The existing lock code was refactored to expose a
lock object that all types of locks use. If RTEMS is built with RTEMS_DEBUG the
locks are held on a list that can be walked with a debugger to aid debugging.

- A proc0 is added. This is the FreeBSD initial process from which all FreeBSD
processes are created from. RTEMS is a single process OS and proc0 is the only
process. The process is required to hold the file descriptors and files the
process has open. It also holds the credentials. The VFS and file system code
all depend on these being present and valid. Only defaults are supported. Adding
a proc0 cleans up a lot of the code that checks for the process a thread belongs
too.

- Kernel Trace or KTR is now supported. You can add a waf configure option to
turn KTR on. KTR is useful with the VFS and file systems.

4475-inmport-vfs-fs
-------------------

The direct import of the FreeBSD code without changes.

4475-vfs
--------

This is large patch that contains:

- VFS changes for libbsd
- File descriptor and file changes for libbsd with tracing
- LibIO integration changes with tracing
- System call (syscall) interface with tracing

See `waf --help` for the tracing options

File Descriptors and Files
==========================

LibIO file descriptors (fd) map to a FreeBSd fds and from that to a FreeBSD file
object or vnodes. The code around this is made more complicated because of the
of the limited fields available in a LibIO iop to hold the data needed. The
LibIO iop can hold the fd and/or vnode pointers for a vnode or a parent vnode.

The select call requires special treatment to handle the different bitmaps
because the user provided bitmap is based on the LibIO fds and not the FB fds.

The kqueue iop holds the knote data kqueue uses.

A lot of functionality has been moved into rtemsbsd and related sources.

Range locking is not supported.

VFS
===

The VFS support means the syscall interfaces can be centralised into rtembsd and
a number of places direct libio access was implemented have be reverted to the
FB code. For example sockets and pipes.

The VFS paging and and VM is not supported. The bio is direct to the devices.
The VFS does start its worker threads to handle flushing and the other related
activities it runs.

File System
-----------

The pseudo file system provides a VFS file we can use to create a root file
system that is mounted in the RTEMS file system. FreeBSD file systems are
mounted onto this root file system.

Chris