From: Arnd Bergmann <arnd@arndb.de>
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: Mon, 8 Aug 2022 16:01:57 +0200 [thread overview]
Message-ID: <CAK8P3a3ZNbmND-TPLEmc-37ZmK31pOT2+hDhQD+HWQZyXFZX8Q@mail.gmail.com> (raw)
In-Reply-To: <163410.1659964655@warthog.procyon.org.uk>
On Mon, Aug 8, 2022 at 3:17 PM David Howells <dhowells@redhat.com> wrote:
>
> Hi,
>
> 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?
>
> David
> ---
> uapi: Remove the inclusion of linux/mount.h from uapi/linux/fs.h
>
> Remove the inclusion of <linux/mount.h> from uapi/linux/fs.h as it
> interferes with definitions in sys/mount.h - but linux/fs.h is needed by
> various things where mount flags and structs are not.
>
> Note that this will likely have the side effect of causing some build
> failures.
>
> Reported-by: Ian Kent <raven@themaw.net>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Alexander Viro <viro@zeniv.linux.org.uk>
> cc: Christian Brauner <christian@brauner.io>
> cc: linux-fsdevel@vger.kernel.org
> cc: linux-api@vger.kernel.org
I think that's probably ok. Looking through the results from
https://codesearch.debian.net/search?q=MS_RDONLY
combined with the list of results from
https://codesearch.debian.net/search?q=linux/fs.h
I found 95 packages that mention both /somewhere/ in the code, see
below for a complete list. I did not try an exhaustive search but found
that almost all of these reference the two in different files.
The only counterexample I found is
https://sources.debian.org/src/trinity/1.9+git20200331.4d2343bd18c7b-2/syscalls/mount.c/?hl=13#L13
so this will likely break and have to get fixed to includle <linux/mount.h> or
<sys/mount.h> instead of linux/fs.h, but that is probably acceptable.
There may be others like it, but not a ton of them.
Arnd
8<---
android-framework-23
android-platform-art
android-platform-frameworks-base
android-platform-system-core
android-platform-system-extras
android-platform-tools
apparmor
audit
avfs
bazel-bootstrap
bcachefs-tools
bpfcc
busybox
cargo
cde
ceph
chromium
criu
cryptmount
docker.io
e2fsprogs
elogind
emscripten
falcosecurity-libs
firefox
firefox-esr
fstransform
gcc-10
gcc-11
gcc-12
gcc-9
gcc-snapshot
gfarm
glibc
glusterfs
gnumach
golang-1.11
golang-1.15
golang-1.16
golang-1.17
golang-1.18
golang-1.19
golang-github-containers-storage
golang-golang-x-sys
golang-inet-netstack
hashrat
hurd
icingadb
kfreebsd-10
klibc
kubernetes
kvmtool
libblockdev
libexplain
librsvg
libvirt
linux
linux-apfs-rw
lxc
manpages-l10n
mergerfs
mozjs91
mtd-utils
network-manager
nilfs-tools
ntfs-3g
ocfs2-tools
ostree
partclone
ploop
qemu
quota
rust-libc
rustc
sash
snapd
strace
stress-ng
suricata
systemd
systemtap
testdisk
thunderbird
tiny-initramfs
tomoyo-tools
toybox
trinity
u-boot
uclibc
umview
util-linux
virtualbox
webhook
zfs-linux
zulucrypt
next prev parent reply other threads:[~2022-08-08 14:02 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 [this message]
2022-08-09 12:30 ` Christian Brauner
2022-08-10 9:26 ` Florian Weimer
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=CAK8P3a3ZNbmND-TPLEmc-37ZmK31pOT2+hDhQD+HWQZyXFZX8Q@mail.gmail.com \
--to=arnd@arndb.de \
--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).