Re: [dmidecode] [PATCH] Prefer SMBIOS3 when read entry point from efi systab

[Jean Delvare]

On Fri, 07 Oct 2016 10:11:26 +0200, Petr Oros wrote:
> Jean Delvare píše v Fri 07. 10. 2016 v 10:00 +0200:
> > Hi Petr,
> > 
> > Please Cc dmidecode patches to the dmidecode-devel list.
> Ok
> 
> > On Thu, 06 Oct 2016 11:15:44 +0200, Petr Oros wrote:
> > > 
> > > From 61c2e2b0c3b3c1e103b6648c9450f4c2e8efec52 Mon Sep 17 00:00:00
> > > 2001
> > > From: Petr Oros <address@hidden>
> > > Date: Thu, 6 Oct 2016 10:48:07 +0200
> > > Subject: [PATCH] Prefer SMBIOS3 when read entry point from efi
> > > systab
> > > 
> > >   According to the DMTF SMBIOS reference spec v3.0.0, it is
> > >   allowed to define both the 64-bit entry point (smbios3) and
> > >   the 32-bit entry point (smbios), in which case they should
> > >   either both point to the same SMBIOS structure table, or the
> > >   table pointed to by the 64-bit entry point should contain a
> > >   superset of the table contents pointed to by the 32-bit entry
> > >   point (section 5.2)
> > > 
> > >   In this case /sys/firmware/efi/systab can contain:
> > > 
> > >     ACPI20=0x7cefe014
> > >     ACPI=0x7cefe000
> > >     SMBIOS=0x00dead00
> > >     SMBIOS3=0xffdeadff
> > 
> > This is a very interesting address :-D
> :)
> > > 
> > >   But for this case, processing end when found
> > >   first record and dmidecode fall back to older
> > >   table and ignore newer version. With this patch,
> > >   processing continue and SMBIOS accept only
> > >   if have not SMBIOS3 version.
> > 
> > This was fixed over a year ago in the kernel:
> > 
> > Author: Jean Delvare <address@hidden>
> > Date:   Thu Apr 30 15:23:05 2015 +0200
> > 
> >     efi: dmi: List SMBIOS3 table before SMBIOS table
> > 
> > I suggest you simply backport this fix to your kernel.
> OK, it will be better solution.
> Note: From the other side, with this patch dmidecode will work
> everywhere ;)

Correct, but this is a more expensive solution, because you have to
read the whole file even if you have found an SMBIOS entry point. Not
that the file is so large that it would really matter... But I see no
reason to make the code slower and more complex if we don't have to,
especially when only 3 kernel versions have the entries in the wrong
order (v3.19 to v4.1.)

-- 
Jean Delvare
SUSE L3 Support