[PATCH] linux: Fix sys/mount.h usage with kernel headers
Florian Weimer
fweimer@redhat.com
Wed Aug 10 15:27:38 GMT 2022
* 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
More information about the Libc-alpha
mailing list