On 8 March 2015 at 18:11, Jean Delvare <[email protected]> wrote: > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote: >> On 8 March 2015 at 12:31, Jean Delvare <[email protected]> wrote: >> > On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote: >> >> The specification doesn't oblige firmware to provide two entry points. >> >> An implementation may provide either the 32-bit entry point or the 64-bit >> >> entry point, or both. For compatibility with existing SMBIOS parsers, an >> >> implementation should provide the 32-bit entry point, but it's not >> >> required. >> > >> > I expect most implementations will do, as it's trivial to implement. >> >> Not quite. First of all, some 64-bit ARM systems do not have any >> system RAM below 4 GB, so there is not way they can implement the >> 32-bit entry point. > > I didn't know that, thanks for the notice. No big deal anyway, these > systems did not support SMBIOS before version 3.0 so there cannot be > any regression on these systems. > >> Also, the 64-bit entry point does not limit the >> structure size or the entire table to 64 KB like the 32-bit one does, >> so it may be necessary to create a whole separate table with a subset >> of the contents of the real table to stay within limits for the 32-bit >> entry point. > > I doubt this is an issue in practice. I have been around for quite some > time now and the largest table I've ever seen was 9043 byte long, which > is nowhere close to the limit. > >> 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? -- Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
