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

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

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]