[libvirt] [PATCH] Load CPU map from builddir when run uninstalled

When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Not only because there may not be any libvirt installed at all. We already do a good job for plugins but cpu_map.xml was still loaded from the system. The Makefile.am change is necessary to make this all work from VPATH builds since libvirtd has no idea where to find libvirt sources. It only knows the path from which it was started, i.e, a builddir. https://bugzilla.redhat.com/show_bug.cgi?id=1074327 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- daemon/libvirtd.c | 7 ++++++- src/Makefile.am | 4 ++++ src/cpu/cpu_map.c | 3 +++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 72f0e81..d91e1e9 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -103,6 +103,7 @@ #include "configmake.h" #include "virdbus.h" +#include "cpu/cpu_map.h" #if WITH_SASL virNetSASLContextPtr saslCtxt = NULL; @@ -1155,13 +1156,16 @@ int main(int argc, char **argv) { if (strstr(argv[0], "lt-libvirtd") || strstr(argv[0], "/daemon/.libs/libvirtd")) { char *tmp = strrchr(argv[0], '/'); + char *cpumap; if (!tmp) { fprintf(stderr, _("%s: cannot identify driver directory\n"), argv[0]); exit(EXIT_FAILURE); } *tmp = '\0'; char *driverdir; - if (virAsprintfQuiet(&driverdir, "%s/../../src/.libs", argv[0]) < 0) { + if (virAsprintfQuiet(&driverdir, "%s/../../src/.libs", argv[0]) < 0 || + virAsprintfQuiet(&cpumap, "%s/../../src/cpu/cpu_map.xml", + argv[0]) < 0) { fprintf(stderr, _("%s: initialization failed\n"), argv[0]); exit(EXIT_FAILURE); } @@ -1174,6 +1178,7 @@ int main(int argc, char **argv) { #ifdef WITH_DRIVER_MODULES virDriverModuleInitialize(driverdir); #endif + cpuMapOverride(cpumap); *tmp = '/'; /* Must not free 'driverdir' - it is still used */ } diff --git a/src/Makefile.am b/src/Makefile.am index 25d0370..306880b 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -977,6 +977,10 @@ libvirt_la_BUILT_LIBADD += libvirt_cpu.la libvirt_cpu_la_CFLAGS = \ -I$(top_srcdir)/src/conf $(AM_CFLAGS) libvirt_cpu_la_SOURCES = $(CPU_SOURCES) +libvirt_cpu_la_DEPENDENCIES = $(abs_builddir)/cpu/cpu_map.xml + +$(abs_builddir)/cpu/cpu_map.xml: + $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@ if WITH_VMX noinst_LTLIBRARIES += libvirt_vmx.la diff --git a/src/cpu/cpu_map.c b/src/cpu/cpu_map.c index 7c2bdec..f6c63d4 100644 --- a/src/cpu/cpu_map.c +++ b/src/cpu/cpu_map.c @@ -28,6 +28,7 @@ #include "cpu_map.h" #include "configmake.h" #include "virstring.h" +#include "virlog.h" #define VIR_FROM_THIS VIR_FROM_CPU @@ -86,6 +87,8 @@ int cpuMapLoad(const char *arch, int element; const char *mapfile = (cpumap ? cpumap : CPUMAPFILE); + VIR_DEBUG("Loading CPU map from %s", mapfile); + if (arch == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("undefined hardware architecture")); -- 1.9.0

On Mon, Mar 10, 2014 at 04:26:30PM +0100, Jiri Denemark wrote:
When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Not only because there may not be any libvirt installed at all. We already do a good job for plugins but cpu_map.xml was still loaded from the system.
The Makefile.am change is necessary to make this all work from VPATH builds since libvirtd has no idea where to find libvirt sources. It only knows the path from which it was started, i.e, a builddir.
https://bugzilla.redhat.com/show_bug.cgi?id=1074327 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Works for me, so you can add: Tested-by: Richard W.M. Jones <rjones@redhat.com> Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

On 03/10/2014 09:26 AM, Jiri Denemark wrote:
When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Not only because there may not be any libvirt installed at all. We already do a good job for plugins but cpu_map.xml was still loaded from the system.
The Makefile.am change is necessary to make this all work from VPATH builds since libvirtd has no idea where to find libvirt sources. It only knows the path from which it was started, i.e, a builddir.
+++ b/src/Makefile.am @@ -977,6 +977,10 @@ libvirt_la_BUILT_LIBADD += libvirt_cpu.la libvirt_cpu_la_CFLAGS = \ -I$(top_srcdir)/src/conf $(AM_CFLAGS) libvirt_cpu_la_SOURCES = $(CPU_SOURCES) +libvirt_cpu_la_DEPENDENCIES = $(abs_builddir)/cpu/cpu_map.xml + +$(abs_builddir)/cpu/cpu_map.xml: + $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@
Does this really work in both VPATH (create the link) and in-tree builds (you would be linking a file to itself, but then again the file is already up-to-date so the ln doesn't get run)? Does it pass 'make distcheck'? It looks a bit odd to me, but if it works, I'm okay ACKing it. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On Mon, Mar 10, 2014 at 12:31:00 -0600, Eric Blake wrote:
On 03/10/2014 09:26 AM, Jiri Denemark wrote:
When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Not only because there may not be any libvirt installed at all. We already do a good job for plugins but cpu_map.xml was still loaded from the system.
The Makefile.am change is necessary to make this all work from VPATH builds since libvirtd has no idea where to find libvirt sources. It only knows the path from which it was started, i.e, a builddir.
+++ b/src/Makefile.am @@ -977,6 +977,10 @@ libvirt_la_BUILT_LIBADD += libvirt_cpu.la libvirt_cpu_la_CFLAGS = \ -I$(top_srcdir)/src/conf $(AM_CFLAGS) libvirt_cpu_la_SOURCES = $(CPU_SOURCES) +libvirt_cpu_la_DEPENDENCIES = $(abs_builddir)/cpu/cpu_map.xml + +$(abs_builddir)/cpu/cpu_map.xml: + $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@
Does this really work in both VPATH (create the link) and in-tree builds (you would be linking a file to itself, but then again the file is already up-to-date so the ln doesn't get run)? Does it pass 'make distcheck'? It looks a bit odd to me, but if it works, I'm okay ACKing it.
It works in in-tree builds as well as VPATH builds as long as VPATH is not relative. Thanks for suggesting make distcheck, which revealed this bug. The link command needs to be changed to $(AM_V_GEN)ln -s $(abs_srcdir)/cpu/cpu_map.xml $@ so that it also works in relative VPATH build. Jirka

On Tue, Mar 11, 2014 at 11:05:34 +0100, Jiri Denemark wrote:
On Mon, Mar 10, 2014 at 12:31:00 -0600, Eric Blake wrote:
On 03/10/2014 09:26 AM, Jiri Denemark wrote:
When libvirtd is run from a build directory without being installed, it should not depend on files from a libvirt package installed in the system. Not only because there may not be any libvirt installed at all. We already do a good job for plugins but cpu_map.xml was still loaded from the system.
The Makefile.am change is necessary to make this all work from VPATH builds since libvirtd has no idea where to find libvirt sources. It only knows the path from which it was started, i.e, a builddir.
+++ b/src/Makefile.am @@ -977,6 +977,10 @@ libvirt_la_BUILT_LIBADD += libvirt_cpu.la libvirt_cpu_la_CFLAGS = \ -I$(top_srcdir)/src/conf $(AM_CFLAGS) libvirt_cpu_la_SOURCES = $(CPU_SOURCES) +libvirt_cpu_la_DEPENDENCIES = $(abs_builddir)/cpu/cpu_map.xml + +$(abs_builddir)/cpu/cpu_map.xml: + $(AM_V_GEN)ln -s $(srcdir)/cpu/cpu_map.xml $@
Does this really work in both VPATH (create the link) and in-tree builds (you would be linking a file to itself, but then again the file is already up-to-date so the ln doesn't get run)? Does it pass 'make distcheck'? It looks a bit odd to me, but if it works, I'm okay ACKing it.
It works in in-tree builds as well as VPATH builds as long as VPATH is not relative. Thanks for suggesting make distcheck, which revealed this bug. The link command needs to be changed to
$(AM_V_GEN)ln -s $(abs_srcdir)/cpu/cpu_map.xml $@
so that it also works in relative VPATH build.
I pushed the patch with this small change squashed in after checking with Eric this satisfies the "if it works, I'm okay ACKing it" condition. Jirka
participants (3)
-
Eric Blake
-
Jiri Denemark
-
Richard W.M. Jones