On 02/06/2012 01:36 AM, Prerna Saxena wrote:
> From: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list