[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-u
Re: [Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-util
Thu, 31 May 2018 13:39:38 -0400
> 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.
> 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)
> #define qemu_fgetxattr fgetxattr
Sounds good. I'll do this in a separate patch, since the *at versions
are all similar while
this is a bit different.
[Qemu-devel] [PATCH 02/13] 9p: Avoid warning if FS_IOC_GETVERSION is not defined, keno, 2018/05/26
[Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-util, keno, 2018/05/26
[Qemu-devel] [PATCH 04/13] 9p: darwin: Handle struct stat(fs) differences, keno, 2018/05/26
[Qemu-devel] [PATCH 05/13] 9p: darwin: Handle struct dirent differences, keno, 2018/05/26
[Qemu-devel] [PATCH 06/13] 9p: darwin: Address minor differences, keno, 2018/05/26