> 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.
Ah sorry, you're correct of course. Will fix. >> 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 > Sounds good. I'll do this in a separate patch, since the *at versions are all similar while this is a bit different.