From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Laurent Vivier" <laurent@vivier.eu>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: [PATCH 2/2] Revert "linux-user: fix compat with glibc >= 2.36 sys/mount.h"
Date: Tue, 10 Jan 2023 12:49:01 -0500 [thread overview]
Message-ID: <20230110174901.2580297-3-berrange@redhat.com> (raw)
In-Reply-To: <20230110174901.2580297-1-berrange@redhat.com>
This reverts commit 3cd3df2a9584e6f753bb62a0028bd67124ab5532.
glibc has fixed (in 2.36.9000-40-g774058d729) the problem
that caused a clash when both sys/mount.h annd linux/mount.h
are included, and backported this to the 2.36 stable release
too:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
It is saner for QEMU to remove the workaround it applied for
glibc 2.36 and expect distros to ship the 2.36 maint release
with the fix. This avoids needing to add a further workaround
to QEMU to deal with the fact that linux/brtfs.h now also pulls
in linux/mount.h via linux/fs.h since Linux 6.1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
linux-user/syscall.c | 18 ------------------
meson.build | 2 --
2 files changed, 20 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9c1e9555e1..f2b7634f5e 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -95,25 +95,7 @@
#include <linux/soundcard.h>
#include <linux/kd.h>
#include <linux/mtio.h>
-
-#ifdef HAVE_SYS_MOUNT_FSCONFIG
-/*
- * glibc >= 2.36 linux/mount.h conflicts with sys/mount.h,
- * which in turn prevents use of linux/fs.h. So we have to
- * define the constants ourselves for now.
- */
-#define FS_IOC_GETFLAGS _IOR('f', 1, long)
-#define FS_IOC_SETFLAGS _IOW('f', 2, long)
-#define FS_IOC_GETVERSION _IOR('v', 1, long)
-#define FS_IOC_SETVERSION _IOW('v', 2, long)
-#define FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap)
-#define FS_IOC32_GETFLAGS _IOR('f', 1, int)
-#define FS_IOC32_SETFLAGS _IOW('f', 2, int)
-#define FS_IOC32_GETVERSION _IOR('v', 1, int)
-#define FS_IOC32_SETVERSION _IOW('v', 2, int)
-#else
#include <linux/fs.h>
-#endif
#include <linux/fd.h>
#if defined(CONFIG_FIEMAP)
#include <linux/fiemap.h>
diff --git a/meson.build b/meson.build
index 175517eafd..32fed7ea6e 100644
--- a/meson.build
+++ b/meson.build
@@ -2039,8 +2039,6 @@ config_host_data.set('HAVE_OPTRESET',
cc.has_header_symbol('getopt.h', 'optreset'))
config_host_data.set('HAVE_IPPROTO_MPTCP',
cc.has_header_symbol('netinet/in.h', 'IPPROTO_MPTCP'))
-config_host_data.set('HAVE_SYS_MOUNT_FSCONFIG',
- cc.has_header_symbol('sys/mount.h', 'FSCONFIG_SET_FLAG'))
# has_member
config_host_data.set('HAVE_SIGEV_NOTIFY_THREAD_ID',
--
2.38.1
next prev parent reply other threads:[~2023-01-10 19:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 17:48 [PATCH 0/2] linux-user: revert previous workaround for glibc >= 2.36 Daniel P. Berrangé
2023-01-10 17:49 ` [PATCH 1/2] Revert "linux-user: add more compat ioctl definitions" Daniel P. Berrangé
2023-01-10 17:49 ` Daniel P. Berrangé [this message]
2023-01-11 9:55 ` [PATCH 0/2] linux-user: revert previous workaround for glibc >= 2.36 Marc-André Lureau
2023-01-25 13:30 ` Laurent Vivier
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=20230110174901.2580297-3-berrange@redhat.com \
--to=berrange@redhat.com \
--cc=laurent@vivier.eu \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.