On Fri, 21 Oct 2022 at 15:50, Daniel P. Berrangé <berra...@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 <laur...@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... -- PMM
