| Message ID | 20221004093206.652431-4-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | linux-user: fix regression with some ioctls with newest glibc | expand |
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. -- PMM
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
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. Thanks, Laurent
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. thanks -- PMM
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 ? With regards, Daniel
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... -- PMM
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
Daniel P. Berrangé <berrange@redhat.com> writes: > 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 ? Well purely selfishly the big build box I have access to is still on 18.04 which is currently running 4.15.0-191-generic. It will hopefully get upgraded before 18.04 goes out of support from Canonical. From a practical point of view it will be a pain if I can't bisect on it in the meantime. > > > With regards, > Daniel
On Tue, Oct 04, 2022 at 10:32:05AM +0100, Daniel P. Berrangé 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. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > meson.build | 12 ++++++++++++ > 1 file changed, 12 insertions(+) Since there's no agreement, I'll just consider this patch discarded, along with the next one. I won't repost since Laurent has already queued the first two patches. With regards, Daniel
diff --git a/meson.build b/meson.build index 8dc661363f..ea434767ac 100644 --- a/meson.build +++ b/meson.build @@ -248,6 +248,18 @@ if targetos == 'linux' add_project_arguments('-isystem', meson.current_source_dir() / 'linux-headers', '-isystem', 'linux-headers', language: ['c', 'cpp']) + + if not cc.compiles(''' + #include <linux/version.h> + int main(void) { +#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 18, 0) +#error "QEMU requires Linux kernel headers version >= 4.18.0" +#endif + return 0; + }''') + error('QEMU requires Linux kernel headers version >= 4.18.0') +endif + endif add_project_arguments('-iquote', '.',
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. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- meson.build | 12 ++++++++++++ 1 file changed, 12 insertions(+)