qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/4] meson: enforce a minimum Linux kernel headers version >=


From: Daniel P . Berrangé
Subject: Re: [PATCH 3/4] meson: enforce a minimum Linux kernel headers version >= 4.18
Date: Fri, 21 Oct 2022 16:28:55 +0100
User-agent: Mutt/2.2.7 (2022-08-07)

On Fri, Oct 21, 2022 at 04:05:27PM +0100, Peter Maydell wrote:
> On Fri, 21 Oct 2022 at 15:50, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Fri, Oct 21, 2022 at 03:38:38PM +0100, Peter Maydell wrote:
> > > On Fri, 21 Oct 2022 at 15:30, Laurent Vivier <laurent@vivier.eu> wrote:
> > > >
> > > > Le 04/10/2022 à 11:32, Daniel P. Berrangé a écrit :
> > > > > 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.
> > > >
> > > > As this change affects entire QEMU build, I'd prefer to have some 
> > > > "Acked-by" before merging it via
> > > > linux-user branch.
> > >
> > > I still think we should be more conservative about kernel header
> > > requirements than we are for other dependencies.
> >
> > How much more though ?  What other distros do we want to target that
> > we don't already cover with our targetted platforms  ?
> 
> I don't want to target them. I just don't want to leave them
> completely stuck. I think system headers are significantly
> different from just needing to build a local version of some
> dependency library.



> 
> Alternatively if we really need recent kernel headers to build
> linux-user then we should come up with some scheme for using
> a local copy of the relevant headers, as we do for KVM...

This wasn't so much about needing recent headers, rather it was
about removing conditionals that are not likely to be needed by
anyone. I wanted to set a min kernel version to make it clearer
to future authors how far back they need to care about compat
for.

The next patch removed conditions for:

  2.5.66 (??)
  2.6.0  (Dec 2003)
  4.2    (Aug 2015)
  4.12   (Jul 2017)

I can't imagine anyone needs 2.6.x support.  Perhaps 4.x if
someone is still using RHEL-7 though

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]