[PATCH v1] meson: fix xenstore and xentoollog detection
A xenstore.pc and xentoollog.pc exists only since Xen 4.9. Fixes commit fe7c07adac30994dd042515e1076e195128e15cd Signed-off-by: Olaf Hering <olaf@aepfle.de> --- meson.build | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/meson.build b/meson.build index 04c229d7f4..f3ff57d336 100644 --- a/meson.build +++ b/meson.build @@ -1500,14 +1500,22 @@ if not get_option('driver_libxl').disabled() and conf.has('WITH_LIBVIRTD') endif xl_util_dep = dependency('xlutil') - xen_store_dep = dependency('xenstore') + # xenstore.pc exists since Xen 4.9 + if libxl_dep.version().version_compare('>=4.9.0') + xen_store_dep = dependency('xenstore') + else + xen_store_dep = cc.find_library('xenstore') + endif # xtl_* infrastructure is in libxentoollog since Xen 4.7 previously # it was in libxenctrl. - if libxl_dep.version().version_compare('>=4.7.0') + # xentoollog.pc exists since Xen 4.9 + if libxl_dep.version().version_compare('>=4.9.0') xtl_link_dep = dependency('xentoollog') + elif libxl_dep.version().version_compare('>=4.7.0') + xtl_link_dep = cc.find_library('xentoollog') else - xtl_link_dep = dependency('xenctrl') + xtl_link_dep = cc.find_library('xenctrl') endif if libxl_dep.version().version_compare('>=4.13.0')
On Mon, Jun 14, 2021 at 10:28:31AM +0200, Olaf Hering wrote:
A xenstore.pc and xentoollog.pc exists only since Xen 4.9.
What OS that libvirt supports ships Xen < 4.9? Pavel
Fixes commit fe7c07adac30994dd042515e1076e195128e15cd
Signed-off-by: Olaf Hering <olaf@aepfle.de> --- meson.build | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build index 04c229d7f4..f3ff57d336 100644 --- a/meson.build +++ b/meson.build @@ -1500,14 +1500,22 @@ if not get_option('driver_libxl').disabled() and conf.has('WITH_LIBVIRTD') endif xl_util_dep = dependency('xlutil')
- xen_store_dep = dependency('xenstore') + # xenstore.pc exists since Xen 4.9 + if libxl_dep.version().version_compare('>=4.9.0') + xen_store_dep = dependency('xenstore') + else + xen_store_dep = cc.find_library('xenstore') + endif
# xtl_* infrastructure is in libxentoollog since Xen 4.7 previously # it was in libxenctrl. - if libxl_dep.version().version_compare('>=4.7.0') + # xentoollog.pc exists since Xen 4.9 + if libxl_dep.version().version_compare('>=4.9.0') xtl_link_dep = dependency('xentoollog') + elif libxl_dep.version().version_compare('>=4.7.0') + xtl_link_dep = cc.find_library('xentoollog') else - xtl_link_dep = dependency('xenctrl') + xtl_link_dep = cc.find_library('xenctrl') endif
if libxl_dep.version().version_compare('>=4.13.0')
On Mon, Jun 14, 2021 at 11:27:32AM +0200, Olaf Hering wrote:
Am Mon, 14 Jun 2021 11:13:54 +0200 schrieb Pavel Hrdina <phrdina@redhat.com>:
What OS that libvirt supports ships Xen < 4.9?
I don't know if that matters. A few lines above in meson.build Xen 4.6 is the supported base.
It matters in a way that we can bump the minimal version to 4.9 and we can simplify the code a bit more. Pavel
Am Mon, 14 Jun 2021 11:54:56 +0200 schrieb Pavel Hrdina <phrdina@redhat.com>:
It matters in a way that we can bump the minimal version to 4.9 and we can simplify the code a bit more.
I will leave this up to Jim if such thing can be justified. It may not matter much for code in libxl. Olaf
On Mon, Jun 14, 2021 at 11:54:56AM +0200, Pavel Hrdina wrote:
On Mon, Jun 14, 2021 at 11:27:32AM +0200, Olaf Hering wrote:
Am Mon, 14 Jun 2021 11:13:54 +0200 schrieb Pavel Hrdina <phrdina@redhat.com>:
What OS that libvirt supports ships Xen < 4.9?
I don't know if that matters. A few lines above in meson.build Xen 4.6 is the supported base.
It matters in a way that we can bump the minimal version to 4.9 and we can simplify the code a bit more.
Repology reports the following openSUSE Leap 15.2: 4.13 openSUSE Leap 15.3: 4.14 Fedora 33: 4.14 Ubuntu 18.04: 4.9 Ubuntu 20.04: 4.11 Debian Stable: 4.11 So we can likely bump it to have 4.9 as the min version at this point in time. 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 :|
Am Mon, 14 Jun 2021 11:06:51 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Repology reports the following
Is it expected that people replace just "libvirt" on a system, and leave everything as it is? If I would build a Xen server, the obvious change is to also replace Xen with the variant I want or need. Well, and that is exactly what I do. For testing I have to run old variants of it, and I expect that libvirt can deal with it. Right now it does. I will be really disappointed if the base line is bumped for no good reason. "cc.find_library" has to be supported for other libraries anyway, so there is no downside to use it if "dependency" can not be used. How much libxl code could be removed, no idea. Without looking I say its likely not worth. Olaf
On Mon, Jun 14, 2021 at 03:24:03PM +0200, Olaf Hering wrote:
Am Mon, 14 Jun 2021 11:06:51 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Repology reports the following
Is it expected that people replace just "libvirt" on a system, and leave everything as it is?
If I would build a Xen server, the obvious change is to also replace Xen with the variant I want or need.
Well, and that is exactly what I do. For testing I have to run old variants of it, and I expect that libvirt can deal with it. Right now it does. I will be really disappointed if the base line is bumped for no good reason. "cc.find_library" has to be supported for other libraries anyway, so there is no downside to use it if "dependency" can not be used. How much libxl code could be removed, no idea. Without looking I say its likely not worth.
None of these questions generally have clear cut answers. Thus libvirt follows the same policy as QEMU for supporting platforms, in that we'll aim to support the 2 most recent releases of any major OS distro. This gives a clear rule for how we decide the minimum version of any package, with results that are consistent across the whole distro package set. eg there's no point keeping Xen support for an old distro if we've dropped support for the GCC / GLib2 version on that same distro, and vica-verca. Based on this policy, it is clear that the Xen minimum should be 4.9 based on version information we can see for the distros. 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 :|
Am Mon, 14 Jun 2021 14:38:19 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Based on this policy, it is clear that the Xen minimum should be 4.9 based on version information we can see for the distros.
Just to wrap up here: The LIBXL_API_VERSION needs to stay at 4.5, because this is the only thing known by Xen 4.9. As a result no code can be removed. There are 4 LIBXL_HAVE_whatever knobs that appeared between Xen 4.6 and 4.9. As a result only a few lines of #ifdef/#endif could be removed, no actual code. So in my opinion it is not worth the effort, the patch for meson.build should be applied as it is. I will leave it to Jim what to do with it. Olaf
On 6/16/21 8:50 AM, Olaf Hering wrote:
Am Mon, 14 Jun 2021 14:38:19 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Based on this policy, it is clear that the Xen minimum should be 4.9 based on version information we can see for the distros.
Just to wrap up here: The LIBXL_API_VERSION needs to stay at 4.5, because this is the only thing known by Xen 4.9.
It's the only LIBXL_API_VERSION known to Xen 4.5-4.12 :-).
As a result no code can be removed. There are 4 LIBXL_HAVE_whatever knobs that appeared between Xen 4.6 and 4.9. As a result only a few lines of #ifdef/#endif could be removed, no actual code.
Sadly, not much can be changed until the minimum supported version can be bumped to 4.13.
So in my opinion it is not worth the effort, the patch for meson.build should be applied as it is.
We are stuck with the 4.5 API through 4.12, but we can still take advantage of other integration-related improvements in Xen such as pkgconfig files. E.g. the attached patch bumps the minimum version to 4.9, which should take care of your issue and makes for one less conditional in meson.build. Opinions? Regards, Jim
On Wed, Jun 16, 2021 at 02:30:45PM -0600, Jim Fehlig wrote:
On 6/16/21 8:50 AM, Olaf Hering wrote:
Am Mon, 14 Jun 2021 14:38:19 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Based on this policy, it is clear that the Xen minimum should be 4.9 based on version information we can see for the distros.
Just to wrap up here: The LIBXL_API_VERSION needs to stay at 4.5, because this is the only thing known by Xen 4.9.
It's the only LIBXL_API_VERSION known to Xen 4.5-4.12 :-).
As a result no code can be removed. There are 4 LIBXL_HAVE_whatever knobs that appeared between Xen 4.6 and 4.9. As a result only a few lines of #ifdef/#endif could be removed, no actual code.
Sadly, not much can be changed until the minimum supported version can be bumped to 4.13.
If i look at current libvirt git I see ifdefs for $ git grep ifdef src/libxl/ | awk '{print $2}' | grep HAVE | sort | uniq > ~/defs LIBXL_HAVE_BUILDINFO_APIC LIBXL_HAVE_BUILDINFO_BOOTLOADER LIBXL_HAVE_BUILDINFO_GRANT_LIMITS LIBXL_HAVE_BUILDINFO_KERNEL LIBXL_HAVE_BUILDINFO_NESTED_HVM LIBXL_HAVE_BUILDINFO_SERIAL_LIST LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST LIBXL_HAVE_CREATEINFO_PASSTHROUGH LIBXL_HAVE_DEVICE_BACKEND_DOMNAME LIBXL_HAVE_DEVICE_CHANNEL LIBXL_HAVE_DOMAIN_NODEAFFINITY LIBXL_HAVE_DOMAIN_SUSPEND_ONLY LIBXL_HAVE_NO_SUSPEND_RESUME LIBXL_HAVE_PVUSB LIBXL_HAVE_QED LIBXL_HAVE_QXL LIBXL_HAVE_SIGCHLD_OWNER_SELECTIVE_REAP LIBXL_HAVE_SOFT_RESET LIBXL_HAVE_SPICE_VDAGENT LIBXL_HAVE_SRM_V2 LIBXL_HAVE_VNUMA Out of those, if I grab the Xen 4.9.3 source code I see #defines for $ for i in `cat ~/defs` ; do grep $i *.h ; done | grep define | awk '{print $2}' LIBXL_HAVE_BUILDINFO_KERNEL LIBXL_HAVE_BUILDINFO_SERIAL_LIST LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST LIBXL_HAVE_DEVICE_BACKEND_DOMNAME LIBXL_HAVE_DEVICE_CHANNEL LIBXL_HAVE_DOMAIN_NODEAFFINITY LIBXL_HAVE_NO_SUSPEND_RESUME LIBXL_HAVE_PVUSB LIBXL_HAVE_QED LIBXL_HAVE_QXL LIBXL_HAVE_SIGCHLD_OWNER_SELECTIVE_REAP LIBXL_HAVE_SOFT_RESET LIBXL_HAVE_SPICE_VDAGENT LIBXL_HAVE_SRM_V2 LIBXL_HAVE_VNUMA That looks like quite a few ifdefs that can be removed ?
So in my opinion it is not worth the effort, the patch for meson.build should be applied as it is.
We are stuck with the 4.5 API through 4.12, but we can still take advantage of other integration-related improvements in Xen such as pkgconfig files. E.g. the attached patch bumps the minimum version to 4.9, which should take care of your issue and makes for one less conditional in meson.build. Opinions?
Regards, Jim
From 0e1f8ff035c19848014b236fe3f9420efabb5ed5 Mon Sep 17 00:00:00 2001 From: Jim Fehlig <jfehlig@suse.com> Date: Mon, 14 Jun 2021 11:17:54 -0600 Subject: [PATCH] Xen: Bump minimum supported Xen version to 4.9
Platforms supported by libvirt have the following Xen versions
openSUSE Leap 15.2: 4.13 openSUSE Leap 15.3: 4.14 Fedora 33: 4.14 Ubuntu 18.04: 4.9 Ubuntu 20.04: 4.11 Debian Stable: 4.11
Bumping the minimum version doesn't allow us to drop much code, but it does provide better alignment with libvirt's platform support statement.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- meson.build | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 :|
On 6/17/21 2:49 AM, Daniel P. Berrangé wrote:
On Wed, Jun 16, 2021 at 02:30:45PM -0600, Jim Fehlig wrote:
On 6/16/21 8:50 AM, Olaf Hering wrote:
Am Mon, 14 Jun 2021 14:38:19 +0100 schrieb Daniel P. Berrangé <berrange@redhat.com>:
Based on this policy, it is clear that the Xen minimum should be 4.9 based on version information we can see for the distros.
Just to wrap up here: The LIBXL_API_VERSION needs to stay at 4.5, because this is the only thing known by Xen 4.9.
It's the only LIBXL_API_VERSION known to Xen 4.5-4.12 :-).
As a result no code can be removed. There are 4 LIBXL_HAVE_whatever knobs that appeared between Xen 4.6 and 4.9. As a result only a few lines of #ifdef/#endif could be removed, no actual code.
Sadly, not much can be changed until the minimum supported version can be bumped to 4.13.
If i look at current libvirt git I see ifdefs for
$ git grep ifdef src/libxl/ | awk '{print $2}' | grep HAVE | sort | uniq > ~/defs LIBXL_HAVE_BUILDINFO_APIC LIBXL_HAVE_BUILDINFO_BOOTLOADER LIBXL_HAVE_BUILDINFO_GRANT_LIMITS LIBXL_HAVE_BUILDINFO_KERNEL LIBXL_HAVE_BUILDINFO_NESTED_HVM LIBXL_HAVE_BUILDINFO_SERIAL_LIST LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST LIBXL_HAVE_CREATEINFO_PASSTHROUGH LIBXL_HAVE_DEVICE_BACKEND_DOMNAME LIBXL_HAVE_DEVICE_CHANNEL LIBXL_HAVE_DOMAIN_NODEAFFINITY LIBXL_HAVE_DOMAIN_SUSPEND_ONLY LIBXL_HAVE_NO_SUSPEND_RESUME LIBXL_HAVE_PVUSB LIBXL_HAVE_QED LIBXL_HAVE_QXL LIBXL_HAVE_SIGCHLD_OWNER_SELECTIVE_REAP LIBXL_HAVE_SOFT_RESET LIBXL_HAVE_SPICE_VDAGENT LIBXL_HAVE_SRM_V2 LIBXL_HAVE_VNUMA
Out of those, if I grab the Xen 4.9.3 source code I see #defines for
$ for i in `cat ~/defs` ; do grep $i *.h ; done | grep define | awk '{print $2}' LIBXL_HAVE_BUILDINFO_KERNEL LIBXL_HAVE_BUILDINFO_SERIAL_LIST LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST LIBXL_HAVE_DEVICE_BACKEND_DOMNAME LIBXL_HAVE_DEVICE_CHANNEL LIBXL_HAVE_DOMAIN_NODEAFFINITY LIBXL_HAVE_NO_SUSPEND_RESUME LIBXL_HAVE_PVUSB LIBXL_HAVE_QED LIBXL_HAVE_QXL LIBXL_HAVE_SIGCHLD_OWNER_SELECTIVE_REAP LIBXL_HAVE_SOFT_RESET LIBXL_HAVE_SPICE_VDAGENT LIBXL_HAVE_SRM_V2 LIBXL_HAVE_VNUMA
That looks like quite a few ifdefs that can be removed ?
Nod. We can remove some ifdefs (Olaf already mentioned that), but the code in libxl_api_wrapper will have to stay for a while. ...
From 0e1f8ff035c19848014b236fe3f9420efabb5ed5 Mon Sep 17 00:00:00 2001 From: Jim Fehlig <jfehlig@suse.com> Date: Mon, 14 Jun 2021 11:17:54 -0600 Subject: [PATCH] Xen: Bump minimum supported Xen version to 4.9
Platforms supported by libvirt have the following Xen versions
openSUSE Leap 15.2: 4.13 openSUSE Leap 15.3: 4.14 Fedora 33: 4.14 Ubuntu 18.04: 4.9 Ubuntu 20.04: 4.11 Debian Stable: 4.11
Bumping the minimum version doesn't allow us to drop much code, but it does provide better alignment with libvirt's platform support statement.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- meson.build | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Thanks. I'll push this and work on a followup patch to remove the unneeded ifdefs. Regards, Jim
participants (4)
-
Daniel P. Berrangé -
Jim Fehlig -
Olaf Hering -
Pavel Hrdina