[libvirt] [PATCH] Bug fix: Allow sysinfo to display processor information

Eric Blake eblake at redhat.com
Mon Feb 6 21:48:17 UTC 2012


On 02/06/2012 01:36 AM, Prerna Saxena wrote:
> From: Prerna Saxena <prerna at linux.vnet.ibm.com>
> Date: Mon, 6 Feb 2012 13:46:10 +0530
> Subject: [PATCH] Bugfix: Allow sysinfo to display 'processor' information
> 
> Calls to virSysinfoParseBIOS(), virSysinfoParseSystem() would update
> the buffer pointer 'base', so the processor information would be lost
> before virSysinfoParseProcessor() was called. Sysinfo would therefore
> not be able to display processor details -- It only described <bios>,
> <system> and <memory_device> details.

What version of dmidecode are you using?  My version,
dmidecode-2.11-5.fc16.x86_64 from Fedora 16, outputs processor after
system, not before bios, when executing 'dmidecode -q -t 0,1,4,17'.

This probably means that not all dmidecode versions output data in the
same order.  NAK to your patch (since while it would fix life on your
machine, it would break life on my machine), but ACK to the bug report
that we should make the code be more tolerant of varying order.

I'm thinking the simplest thing would be to change all of the parser
functions to quit returning an end pointer where they stopped parsing,
and instead to always scan the entire string.  After all, that was only
being done as an optimization to try and do strstr() on smaller portions
of the overall output string.

> +++ b/src/util/sysinfo.c
> @@ -483,16 +483,17 @@ virSysinfoRead(void) {
>  
>      base = outbuf;
>  
> +    ret->nprocessor = 0;
> +    ret->processor = NULL;
> +    if ((base = virSysinfoParseProcessor(base, ret)) == NULL)
> +        goto no_memory;
> +
>      if ((base = virSysinfoParseBIOS(base, ret)) == NULL)
>          goto no_memory;

That is, make calls such as:

if (virSysinfoParseBIOS(outbuf, ret) < 0)
    goto no_memory

after changing virSysinfoParseBIOS to return an int rather than a
pointer inside its incoming argument.

Can you rework this patch along those lines?

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120206/0fe361e9/attachment-0001.sig>


More information about the libvir-list mailing list