From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>,
Eduardo Habkost <eduardo@habkost.net>,
Richard Henderson <richard.henderson@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 3/4] meson: enforce a minimum Linux kernel headers version >= 4.18
Date: Tue, 4 Oct 2022 11:00:20 +0100 [thread overview]
Message-ID: <YzwENEPk8O/Cr3Fm@redhat.com> (raw)
In-Reply-To: <CAFEAcA_UkN17_eitD7ft+y5HBhiD8zmrttWzfaBGM92O6eNTrg@mail.gmail.com>
On Tue, Oct 04, 2022 at 10:49:44AM +0100, Peter Maydell wrote:
> On Tue, 4 Oct 2022 at 10:46, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > Various areas of QEMU have a dependency on Linux kernel header
> > definitions. This falls under the scope of our supported platforms
> > matrix, but historically we've not checked for a minimum kernel
> > headers version. This has made it unclear when we can drop support
> > for older kernel headers.
> >
> > * Alpine 3.14: 5.10
> > * CentOS 8: 4.18
> > * CentOS 9: 5.14
> > * Debian 10: 4.19
> > * Debian 11: 5.10
> > * Fedora 35: 5.19
> > * Fedora 36: 5.19
> > * OpenSUSE 15.3: 5.3.0
> > * Ubuntu 20.04: 5.4
> > * Ubuntu 22.04: 5.15
> >
> > The above ignores the 3rd version digit since distros update their
> > packages periodically and such updates don't generally affect public
> > APIs to the extent that it matters for our build time check.
> >
> > Overall, we can set the baseline to 4.18 currently.
>
> I wonder if we want to be a bit more conservative about this
> than we would for other library-type dependency setting ?
> At the moment, even if you don't meet our minimum distro
> baseline, you can still build by, for instance, building
> local copies of newer versions of our dependencies and using
> those. That seems harder to do for the system header files.
In theory it ought to be possible to install a newer version of the
linux kernel headers too, as there's no need for them to actually
match the kernel being run. Depending on the age difference of
distro vs newer kernel headers though, I guess there's a small risk
of incompatibility between the new kernel headers and original glibc.
Personally I think we're already pretty generous though in terms of
backcompat though, and at least for the user emulators, people can
do a static build on a newer install and run it on an older install.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-10-04 10:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 9:32 [PATCH 0/4] linux-user: fix regression with some ioctls with newest glibc Daniel P. Berrangé
2022-10-04 9:32 ` [PATCH 1/4] linux-user: add more compat ioctl definitions Daniel P. Berrangé
2022-10-21 14:21 ` Laurent Vivier
2022-10-21 15:17 ` Laurent Vivier
2022-10-04 9:32 ` [PATCH 2/4] linux-user: remove conditionals for many fs.h ioctls Daniel P. Berrangé
2022-10-21 14:21 ` Laurent Vivier
2022-10-21 15:17 ` Laurent Vivier
2022-10-04 9:32 ` [PATCH 3/4] meson: enforce a minimum Linux kernel headers version >= 4.18 Daniel P. Berrangé
2022-10-04 9:49 ` Peter Maydell
2022-10-04 10:00 ` Daniel P. Berrangé [this message]
2022-10-21 14:30 ` Laurent Vivier
2022-10-21 14:38 ` Peter Maydell
2022-10-21 14:50 ` Daniel P. Berrangé
2022-10-21 15:05 ` Peter Maydell
2022-10-21 15:28 ` Daniel P. Berrangé
2022-10-21 16:50 ` Alex Bennée
2022-10-27 10:50 ` Daniel P. Berrangé
2022-10-04 9:32 ` [PATCH 4/4] linux-user: drop conditionals for obsolete kernel header versions Daniel P. Berrangé
2022-10-21 14:32 ` 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=YzwENEPk8O/Cr3Fm@redhat.com \
--to=berrange@redhat.com \
--cc=eduardo@habkost.net \
--cc=laurent@vivier.eu \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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).