Re: [PATCH] 9pfs: Add FreeBSD support

[Mark Johnston <markj@freebsd.org>]

On Tue, Aug 05, 2025 at 01:49:44PM +0200, Christian Schoenebeck wrote:
> On Wednesday, July 30, 2025 4:32:22 PM CEST Mark Johnston wrote:
> > On Tue, Jul 29, 2025 at 06:09:35PM +0200, Christian Schoenebeck wrote:
> > > On Wednesday, July 23, 2025 5:55:58 PM CEST Mark Johnston wrote:
> [...]
> > Thank you for taking a look.
> > 
> > I'll certainly be around to help deal with issues and patches relating
> > to 9pfs+FreeBSD hosts.  It's hard to prove that, but for what it's worth
> > I use QEMU fairly extensively for FreeBSD development when I can't use
> > the native hypervisor, and that's not likely to change anytime soon.
> > 
> > Would adding myself to MAINTAINERS for virtio-9pfs (or a new
> > virtio-9pfs-freebsd category) be appropriate in that case?
> 
> Good to hear that you will be around!
> 
> I leave it to you whether you want to add yourself as reviewer of patches to
> MAINTAINER's 9pfs section.

Ok.  I'll leave myself off the list for now then.  If the patch is
applied and any FreeBSD-related problems crop up, please let me know of
course I'll try to fix them ASAP.  If this turns out to be a regular
occurrence (hopefully not), I can add myself and be more proactive about
responding to patches or bug reports.

> > > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> > > > index a1924fe3f0..7315b32591 100644
> > > > --- a/hw/9pfs/9p-util.h
> > > > +++ b/hw/9pfs/9p-util.h
> > > > @@ -21,6 +21,14 @@
> > > >  #define O_PATH_9P_UTIL 0
> > > >  #endif
> > > >  
> > > > +#ifdef CONFIG_FREEBSD
> > > > +/*
> > > > + * FreeBSD does not have these flags, so we can only emulate them (racily).
> > > > + */
> > > > +#define XATTR_CREATE    0x1
> > > > +#define XATTR_REPLACE   0x2
> > > > +#endif
> > > > +
> > > 
> > > What do you mean with "racily" here?
> > 
> > FreeBSD cannot atomically check for the existence of and set an extattr,
> > the system call interface simply doesn't support it today.  This means
> > that fsetxattrat_nofollow() needs back-to-back system calls to check for
> > the existence of an attribute and then potentially set it.
> 
> Ah, I was misinterpreting your comment as if it were "racily defining" the
> macros. Maybe change the comment to something like "... can only emulate their
> intended behaviour (racily) ...".

Done.  I'll send out a v2 shortly.