Re: [Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-util

[Greg Kurz <groug@kaod.org>]

On Thu, 31 May 2018 12:14:30 -0400
Keno Fischer <keno@juliacomputing.com> wrote:

> > I'm ok with this move, but if the functions need to have distinct
> > implementations, and they really do according to patch 10, then
> > I'd rather have distinct files and rely on conditional building in
> > the makefile. Maybe rename the current file to 9p-util-linux.c
> > and introduce a 9p-util-darwin.c later.  
> 
> Sounds good, I will make this change.
> 
> >> Additionally, introduce a _follow version of fgetxattr and use it.
> >> On darwin, fgetxattr has a more general interface, so we'll need to factor
> >> it out anyway.
> >>  
> >
> > No need for the _follow version in this case.  
> 
> I'm not entirely sure what you're proposing. On darwin `fgetxattr`
> takes two extra
> arguments,

Oops you're right... so we indeed need to handle this conflicting APIs,
but fgetxattr_follow() is inapropriate, because fgetxattr() has nothing
to follow since it already has an fd... The same goes with Darwin's
version actually. The "nofollow" thingy only makes sense for those calls
that have a dirfd and pathname argument.

The OSX manpage for fgetxattr() seem to mention the XATTR_NOFOLLOW flag
for getxattr() only.

https://www.unix.com/man-page/osx/2/fgetxattr/

XATTR_NOFOLLOW  do not follow symbolic links.  getxattr() normally returns
		information from the target of path if it is a symbolic link.
		With this option, getxattr() will return extended attribute
		data from the symbolic link instead.

> so I believe it needs to be factored out nevertheless. Are you just
> proposing doing that later in the patch series?

Maybe introduce a qemu_fgetxattr() API in 9p-utils.h ? In a separate patch, or
maybe in patch 10.

#ifdef CONFIG_DARWIN
#define qemu_fgetxattr(...) fgetxattr(__VA_ARGS__, 0, 0)
#else
#define qemu_fgetxattr fgetxattr
#endif