[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point a
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Sun, 8 Mar 2015 19:21:30 +0100
On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 18:11, Jean Delvare <address@hidden> wrote:
> > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> >> And the 32-bit entry point could well be 3.0 anyway, if
> >> it uses any of the new enum values for the data items that were
> >> undefined before 3.0.
> > This is true but irrelevant to the discussion.
> To clarify, the SMBIOS 3.0 spec explicitly allows the 32-bit entry
> point to either point to the same table as the 64-bit entry point, or
> point to a separate table, in which case the contents of the latter
> should be a subset of the contents of the former. It doesn't specify
> anything about the version number to be used in the 32-bit entry point
> in case they point to separate tables. This means the presence of the
> 32-bit entry point does not guarantee that the table contents are
> compatible with the pre-3.0 tools. So perhaps it would make sense to
> export the 32-bit entry point separately only if it points to a
> different table, and has a different version number?
The situation is exactly the same as with every new version of the
SMBIOS specification: tools need to be updated to support the new
enumerated values and the new fields, but are able to decode all the
rest just fine. The only thing that would make it a different situation
is if something in the 3.0 specification is incompatible with previous
specifications. But I'd be very surprised if this is the case, as I am
sure the DMTF people care about compatibility.
And I can't see any practical case where the vendor would want to not
implement version 3.0 in the _SM_-pointed table if they do so for the
_SM3_-pointed table. That's more work for them and serves no purpose,
as everything that could be encoded in old versions can also be encoded
in newer versions.
So, no, I still don't think there is any value in exposing two entry
points in sysfs.
SUSE L3 Support