Re: [PATCH v2 5/5] linux: Fix sys/mount.h usage with kernel headers

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 11/08/22 18:57, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> Now that kernel exports linux/mount.h and includes it on linux/fs.h,
>> its definitions might clash with glibc exports sys/mount.h.  To avoid
>> the need to rearrange the Linux header to be always after glibc one,
>> the glibc sys/mount.h is changed to:
>>
>>   1. Undefine the macros also used as enum constants.  This covers prior
>>      inclusion of <linux/mount.h> (for instance MS_RDONLY).
>>
>>   2. Include <linux/mount.h> based on the usual __has_include check
>>      (needs to use __has_include ("linux/mount.h") to paper over GCC
>>      bugs.
>>
>>   3. Define enum fsconfig_command only if FSOPEN_CLOEXEC is not defined.
>>      (FSOPEN_CLOEXEC should be a very close proxy.)
>>
>>   4. Define struct mount_attr if MOUNT_ATTR_SIZE_VER0 is not defined.
>>      (Added in the same commit on the Linux side.)
>>
>> This patch also adds some tests to check if including linux/fs.h and
>> linux/mount.h after and before sys/mount.h does work.
>>
>> Checked on x86_64-linux-gnu.
> 
> Also built with build-many-glibcs.py.  This version looks good.
> 
> There is a gap with old compilers only (those that don't have
> __has_include), and if <linux/mount.h> is included after <sys/mount.h>,
> but I think that's an acceptable trade-off.

At least gcc 6 does have support for __has_include (or it was backported in
the release branches) which the minimum supported version to build glibc
itself.  I am not sure how common is deployment with gcc version older
with newer glibc, so I agree with the trade-off.

> 
> Reviewed-by: Florian Weimer <fweimer@redhat.com>
> 

Thanks.

> Thanks,
> Florian
>