* David Howells:
We're seeing issues in autofs and xfstests whereby linux/mount.h (the UAPI
version) as included indirectly by linux/fs.h is conflicting with
sys/mount.h (there's a struct and an enum).
Would it be possible to just remove the #include from linux/fs.h (as patch
below) and rely on those hopefully few things that need mount flags that don't
use the glibc header for them working around it by configuration?
Wasn't <linux/mount.h> split from <linux/fs.h> relatively recently, and
userspace is probably using <linux/fs.h> to get the mount flag
definitions?
In retrospect, it would have been better to add the new fsmount stuff to
a separate header file, so that we could include that easily from
<sys/mount.h> on the glibc side. Adhemerval posted a glibc patch to
fake that (for recent compilers):
[PATCH] linux: Fix sys/mount.h usage with kernel headers
<https://sourceware.org/pipermail/libc-alpha/2022-August/141316.html>
I think it should work reliably, so that's probably the direction we are
going to move in.
We'll backport this to 2.36, and distributions will pick it up.
Thanks,
Florian
On 10/8/22 17:26, Florian Weimer wrote:
* David Howells:
quoted
We're seeing issues in autofs and xfstests whereby linux/mount.h (the UAPI
version) as included indirectly by linux/fs.h is conflicting with
sys/mount.h (there's a struct and an enum).
Would it be possible to just remove the #include from linux/fs.h (as patch
below) and rely on those hopefully few things that need mount flags that don't
use the glibc header for them working around it by configuration?
Wasn't <linux/mount.h> split from <linux/fs.h> relatively recently, and
userspace is probably using <linux/fs.h> to get the mount flag
definitions?
Not sure myself but this is in the user space kernel includes
and sys/mount.h has pretty much what linux/mount.h has plus a
few function declarations. It's almost a complete duplication.
The reality is that the enum declaration could be changed to
#defines (not a preferred approach) which leaves only the
struct mount_attr which is the difficult one to resolve.
In retrospect, it would have been better to add the new fsmount stuff to
a separate header file, so that we could include that easily from
<sys/mount.h> on the glibc side. Adhemerval posted a glibc patch to
fake that (for recent compilers):
[PATCH] linux: Fix sys/mount.h usage with kernel headers
<https://sourceware.org/pipermail/libc-alpha/2022-August/141316.html>
I think it should work reliably, so that's probably the direction we are
going to move in.
Looked a lot more complicated than I thought it could be, enough
that I can't say if it will work so I'll take your word for it.
Ian