On 02/07/2012 03:18 AM, Eric Blake wrote:
> 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'.
>
I chanced upon this while using dmidecode-2.10-2.fc14.x86_64. Didnt know
that dmidecode versions might differ in their output.
> 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?
>
Thanks, this seems logical. Will spin a quick patch right away.
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list