On 2/9/16 3:44 PM, Dave Chinner wrote:
> On Tue, Feb 09, 2016 at 03:27:18PM -0600, Eric Sandeen wrote:
>>
>>
>> On 2/9/16 3:10 PM, Dave Chinner wrote:
>>> On Tue, Feb 09, 2016 at 01:57:09PM -0600, Eric Sandeen wrote:
>>>> On 2/9/16 1:55 PM, Dave Chinner wrote:
>>>>> On Tue, Feb 09, 2016 at 11:40:57AM -0600, Eric Sandeen wrote:
>>>>>> After 334e580,
>>>>>> fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR promotion
>>>>>>
>>>>>> the file include/linux/fs.h now defines struct fsxattr.
>>>>>>
>>>>>> It defines FS_IOC_FSGETXATTR as well, so use that to wrap
>>>>>> our local definition, and skip it if the kernel is providing
>>>>>> it so that we don't get multiple definitions.
>>>>>>
>>>>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>>>>>> ---
>>>>>>
>>>>>> Should the kernel also #define HAVE_FSXATTR to help existing
>>>>>> xfsprogs-devel installations?
>>>>>>
>>>>>> (And what if headers are included in the other order? Should
>>>>>> we try to guard on the kernel side or no?)
>>>>>
>>>>> I've already sent a patch to fix this - it was with the foreign
>>>>> filesystem xfs_quota patch....
>>>>
>>>> Oh, sorry, spaced it.
>>>>
>>>> What do you think of the HAVE_FSXATTR definition in fs.h?
>>>
>>> Which fs.h? The include/linux/fs.h file does not have such
>>> guards...
>>
>> If include/linux/fs.h defined HAVE_FSXATTR, a subsequent inclusion
>> of xfs_fs.h would not redefine the structure, because it is
>> guarded with that (for irix!)
>
> That's why I changed it to check if the ioctl is defined, rather
> than checking for HAVE_FSXATTR.
Right, but I'm talking about protecting older, existing versions of
xfsprogs headers which use HAVE_FSXATTR as the guard.
-Eric
|