[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 02/07/2012 03:18 AM, Eric Blake wrote:
> On 02/06/2012 01:36 AM, Prerna Saxena wrote:
>> From: Prerna Saxena <prerna 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'.

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.

Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]