On Thu, 31 May 2018 12:14:30 -0400 Keno Fischer <k...@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
