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

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella Netto:

>>> diff --git a/sysdeps/unix/sysv/linux/sys/mount.h b/sysdeps/unix/sysv/linux/sys/mount.h
>>> index f965986ba8..ae8406838b 100644
>>> --- a/sysdeps/unix/sysv/linux/sys/mount.h
>>> +++ b/sysdeps/unix/sysv/linux/sys/mount.h
>>> @@ -27,6 +27,19 @@
>>>  #include <stddef.h>
>>>  #include <sys/ioctl.h>
>>>  
>>> +#ifdef __has_include
>>> +# if __has_include ("linux/mount.h")
>>> +#  include "linux/mount.h"
>>> +#  ifdef FSOPEN_CLOEXEC
>>> +#   define __mount_fsopen_cloexec_defined 1
>>> +#  endif
>>> +#  ifdef MOUNT_ATTR_SIZE_VER0
>>> +#   define __mount_attr_size_ver0_defined 1
>>> +#  endif
>>> +# endif
>>> +#endif
>> 
>> I think those __mount_ defines are not *that* useful.
>
> Not sure I am following, should I remove them? If so it would require
> some more ifdefs on their usage below.

Yes, basically check FSOPEN_CLOEXEC and MOUNT_ATTR_SIZE_VER0 directly.
It's required to get this to work without __has_include, if I'm not
mistkaen.

>>> +
>>> +#undef BLOCK_SIZE
>>>  #define BLOCK_SIZE	1024
>> 
>> If we don't have enum constants, should we #undef things?  If we
>> redefine as the same token as the kernel, there won't be a preprocessor
>> warning.
>
> This is required because of linux/fs.h (I caught it with the new testcase).
> Not sure if this is really required now that kernel is avoid including
> linux/mount.h on linux/fs.h.

Ah.  BLOCK_SIZE is special:

#define BLOCK_SIZE_BITS 10
#define BLOCK_SIZE (1<<BLOCK_SIZE_BITS)

So not 1024 and hence warning-prone.

But for the other definitions that use integer literals, we should
probably use the same literal as the kernel in our headers and not
#undef these constants (as an additional consistency check).

Thanks,
Florian