Hi Jonathan,
On Thu, 3 Mar 2022 22:30:50 +0000, Jonathan Zhang via dmidecode-devel wrote:
> 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?
It does exactly that on Linux. If you loot at the main() function in
dmidecode.c, you'll find:
/*
* First try reading from sysfs tables. (...)
*/
(...)
/* Next try EFI (ia64, Intel-based Mac, arm64) */
(...)
/* Fallback to memory scan (x86, x86_64) */
if ((buf = mem_chunk(0xF0000, 0x10000, opt.devmem)) == NULL)
That being said, I can't see how this relates to your initial question.
How the SMBIOS entry point address is found has nothing to do with the
table's contents being static or dynamic, and the DMI table seen and
exposed by the kernel is exactly the same as what dmidecode would get
from a memory scan.
--
Jean Delvare
SUSE L3 Support
_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
