Re: git: e97ad33a89a7 - main - Add an implementation of the 9P filesystem

On Wed 19 Jun 12:13, Doug Rabson wrote:
> The branch main has been updated by dfr:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=e97ad33a89a78f55280b0485b3249ee9b907a718
> 
> commit e97ad33a89a78f55280b0485b3249ee9b907a718
> Author:     Doug Rabson <dfr@FreeBSD.org>
> AuthorDate: 2022-12-06 13:07:46 +0000
> Commit:     Doug Rabson <dfr@FreeBSD.org>
> CommitDate: 2024-06-19 12:12:04 +0000
> 
>     Add an implementation of the 9P filesystem
>     
>     This is derived from swills@ fork of the Juniper virtfs with many
>     changes by me including bug fixes, style improvements, clearer layering
>     and more consistent logging. The filesystem is renamed to p9fs to better
>     reflect its function and to prevent possible future confusion with
>     virtio-fs.
>     
>     Several updates and fixes from Juniper have been integrated into this
>     version by Val Packett and these contributions along with the original
>     Juniper authors are credited below.
>     
>     To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
>     bhyve virtio-9p device allows access from the guest to files on the host
>     by mapping a 'sharename' to a host path. It is possible to use p9fs as a
>     root filesystem by adding this to /boot/loader.conf:
>     
>             vfs.root.mountfrom="p9fs:sharename"
>     
>     for non-root filesystems add something like this to /etc/fstab:
>     
>             sharename /mnt p9fs rw 0 0
>     
>     In both examples, substitute the share name used on the bhyve command
>     line.
>     
>     The 9P filesystem protocol relies on stateful file opens which map
>     protocol-level FIDs to host file descriptors. The FreeBSD vnode
>     interface doesn't really support this and we use heuristics to guess the
>     right FID to use for file operations.  This can be confused by privilege
>     lowering and does not guarantee that the FID created for a given file
>     open is always used for file operations, even if the calling process is
>     using the file descriptor from the original open call. Improving this
>     would involve changes to the vnode interface which is out-of-scope for
>     this import.
>     

First of all: thanks a lot! you say the changes in the vnode interface are out
of scope for this import, which makes perfectly sense, but it is part of your
TODO for later?

Best regards,
Bapt