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

On Wed, 19 Jun 2024 at 13:23, Baptiste Daroussin <bapt@freebsd.org> wrote:

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

It is something I would like to work on but I'm not sure exactly when. I
may try a quick-and-dirty approximation to get a better idea about how much
in vnode will need to change. Basically, we need to track state from the
VOP_OPEN in struct file so that we can match the right 9P fid with each i/o
operation. This seems possible since we already have an f_data member in
struct file.

Doug.