[libvirt] [PATCH] udev: Don't try to dump DMI on non-intel archs

[Michal Privoznik]

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