Hi So the smbios spec indicates that it should be static: "The information that is present in the table-based structures is boot-time static, and SMBIOS consumers should not expect the information to be updated during normal system operations, except for the Log Change Token if implemented"
So is this about the Log Change Token? It's not super clear to me what that means from the spec. So currently the spec allows 2 ways to provide smbios to the OS: - Legacy 0xf0000 - UEFI runtime services Some platforms don't implement UEFI, (e.g. coreboot), but still need a flexible way to pass it to the OS. With ACPI there was a similar problem but it was fixed the following way on Linux: e6e094e053af75cbc164e950814d3d084fb1e698 (x86/acpi, x86/boot: Take RSDP address from boot params if available) implements a simple way to pass the ACPI RSDP via the Zero Page. Btw on other architectures there is an even bigger problem with the legacy 0xf0000 not being available, which mandates UEFI to be able to use smbios. This should not be the case. Should the smbios offset be passed via devicetree on non-x86 platforms ( https://www.devicetree.org/)? Arthur Heymans 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: arthur.heym...@9elements.com Phone: *+49 234 68 94 188 <+492346894188>* Mobile: *+32 478499445* Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy> On Thu, 3 Mar 2022 at 23:30, Jonathan Zhang (Infra) <jonzh...@fb.com> wrote: > Hi, > > > > Today smbios table is generated at boot time, as a static blob in reserved > memory region. > > Some of the info becomes stale following hot add/remove events which > becomes > > common nowadays. > > > > I wonder if there is any alternative, or some discussions/plan in progress > to solve this > > problem? Any feedbacks/pointers are appreciated. > > > > One idea is to make sysfs (/sys/firmware/dmi/) to be the source > > of truth for all kernel and user space code which need to > > consume smbios data. It looks like dmidecode hard codes > > the memory region base 0xF0000, why don’t it pick up from > /sys/firmware/dmi? > > > > Thank you, > > Jonathan > > > _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
