On 19.07.2011 17:17, Eric Blake wrote:
On 07/19/2011 09:12 AM, Michal Privoznik wrote:
On 19.07.2011 17:01, Eric Blake wrote:
On 07/19/2011 08:52 AM, Michal Privoznik wrote:
DMI is Intel& Intel-compatible specific. Don't try to dump information
on non-compatible architectures, which results only in error message in
logs.
---
NB: libsmbios is exclusively for x86_64 ia64 %{ix86}
src/node_device/node_device_udev.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
ACK.
But do we also need to patch src/util/sysinfo.c, which makes callouts to
dmidecode(1)? That is, if libsmbios is arch-specific, then I imagine
that so is dmidecode, and do we gracefully handle dmidecode failures in
that case?
You're right. dmidecode is arch-specific as well. Right now we just fail
in running it. Is it enough or should that be enclosed in conditional
compilation as well?
That depends on how things behave on other arches. I don't have ready
access to such an architecture, which is why I'm asking - do we already
gracefully handle any failures on code paths that try to use dmidecode,
or are there currently code paths that make unconditional use of
dmidecode (and fail) which should be made arch-conditional?
It's pointless to write a patch until we know what behavior we're patching.
So I've managed to run libvirt on ppc64. Here are the results:
# virsh sysinfo
error: failed to get sysinfo
error: unsupported configuration: Host SMBIOS information is not available
and in logs:
05:25:40.682: 29653: error : virSysinfoRead:462 : internal error Failed
to find path for dmidecode binary
which get logged on daemon startup, not that virsh command.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list