Hi Jean,
If all kernel/user space smbios consumers get the smbios data from
/sys/firmware/dmi,
the data in /sys/firmware/dmi could be updated by kernel/firmware as part of
hot plug
and hog remove handling procedure; and then the smbios consumers would get
updated
info following hot plug and hot remove event.
In this case, the data in /sys/firmware/dmi is out-of-sync with the data
provided at boot time
(such as the data in the 0xF0000 memory region); but this is okay.
What do you think?
Thanks,
Jonathan
From: Jean Delvare <jdelv...@suse.de>
Date: Monday, March 7, 2022 at 1:55 AM
To: dmidecode-devel@nongnu.org <dmidecode-devel@nongnu.org>
Cc: Jonathan Zhang (Infra) <jonzh...@fb.com>, Ron Minnich
<rminn...@google.com>, Arthur Heymans <arthur.heym...@9elements.com>
Subject: Re: [dmidecode] runtime update of smbios
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
