Re: [dmidecode] [PATCH 1/1] dmioem: HPE OEM Record 199

[Jerry Hoemann]

On Tue, Mar 02, 2021 at 01:57:43PM +0100, Jean Delvare wrote:
> On Mon, 1 Mar 2021 23:11:23 -0700, Jerry Hoemann wrote:
> > On Mon, Mar 01, 2021 at 07:56:31PM +0100, Jean Delvare wrote:

...

> 
> > > > +                               cpuid = DWORD(data + ptr + 2 * 
> > > > sizeof(u32));
> > > > +                               pr_attr("CPUID", "%02X %02X %02X %02X",
> > > > +                                               cpuid & 0xff, (cpuid >> 
> > > > 8) & 0xff,
> > > > +                                               (cpuid >> 16) & 0xff, 
> > > > (cpuid >> 24) & 0xff);  
> > > 
> > > This doesn't seem to be the most popular way to display an x86 CPUID
> > > value. I know of two ways to present that information:
> > > 
> > > 1* Optional type/cpu family/model/stepping, as 3 or 4 decimal numbers.
> > > 
> > > 2* A single, raw hexadecimal number.
> > > 
> > > Splitting into 4 hexadecimal bytes doesn't really make sense, as this
> > > doesn't match the different fields within the 32-bit number.  
> > 
> > 
> > This field contains the output of the CPUID instruction and the printing is
> > consistent with how dmidecode displays the type 4 "ID" field.
> 
> Not really. That field in type 4 is displayed twice. As a raw "ID"
> first, before taking the architecture into account. And then once again
> in an arch-specific way. For i686 and later, this is decoded as
> "Signature" with format strings "Type %u, Family %u, Model %u, Stepping
> %u" (for Intel) or "Family %u, Model %u, Stepping %u" (for AMD).
> 
> > I'm not opposed to changing how we display this, but we should probably
> > also change the display of the type 4 ID field as well to keep consistent.
> > That would make it easier to determine which patch would be applied to
> > the current hardware by matching up the output to:  "dmidecode -t 4 -t 199"
> 
> Reusing the same strings I mentioned above for consistency would be
> perfect, agreed.


Oh, I see.  Type 4 record is printing out the ID twice. Once as hex bytes,
and the second time in more human friendly form.

But, that is way too much code to duplicate. So, we probably
want to pull that code into a standalone function that both
the Type 4 record and the HPE OEM record 199 would call.

Do you want to do this?


Jerry


-- 

-----------------------------------------------------------------------------
Jerry Hoemann                  Software Engineer   Hewlett Packard Enterprise
-----------------------------------------------------------------------------