linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, Ian Kent <raven@themaw.net>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <christian@brauner.io>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] uapi: Remove the inclusion of linux/mount.h from uapi/linux/fs.h
Date: Wed, 10 Aug 2022 11:26:30 +0200	[thread overview]
Message-ID: <87zggce9fd.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <163410.1659964655@warthog.procyon.org.uk> (David Howells's message of "Mon, 08 Aug 2022 14:17:35 +0100")

* 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


  parent reply	other threads:[~2022-08-10  9:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 13:17 [RFC][PATCH] uapi: Remove the inclusion of linux/mount.h from uapi/linux/fs.h David Howells
2022-08-08 14:01 ` Arnd Bergmann
2022-08-09 12:30 ` Christian Brauner
2022-08-10  9:26 ` Florian Weimer [this message]
2022-08-10 13:01   ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zggce9fd.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=christian@brauner.io \
    --cc=dhowells@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).