On 19 January 2015 at 16:57, Ivan Khoronzhuk ivan.khoronzhuk@linaro.org wrote:
On 01/19/2015 06:20 PM, Ard Biesheuvel wrote:
On 19 January 2015 at 16:07, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 16 January 2015 at 17:56, Ivan Khoronzhuk ivan.khoronzhuk@linaro.org wrote:
There are situations when code needs to access SMBIOS entry table area, but cannot use /dev/mem for this. As the table format is consistent only for a version, and can be changed, use binary attribute to give access to raw SMBIOS entry table area.
So now we have a sysfs entry for the entry point, but still need /dev/mem to get at the actual data?
Ignore me, I was looking in the wrong place in /sys
So as I understand it, you need these patches to get at the payload of the entry point, i.e., the version number.
The version number is not only var that can be required by utils. For example, dmidecode needs also print some additional info like phys address where dmitable is placed.
Also I don't sure how exactly next SMBIOS version will be changed. It can happen that some new data is available...and some old is removed. It's better to export it as raw data like it was done for dmi entries via raw attribute.
OK.
Could we instead export the version number directly, and not bother with recording and remapping the structure table? The version is already recorded in dmi_ver afaik,
dmi_ver is not only one var from SMBIOS entry table. It's better pass the whole entry table instead of each time modify the dmi sysfs interface when new SMBIOS version is issued.
I think there is a number of things you can do to simplify this patch: - use the global char[32] i suggested in the other thread - move the create_bin_file call to after dmi_walk() so that it instantiates the sysfs entry only if (dmi_available) - use __BIN_ATTR_RO() instead of opencoding the struct initializers - the file size is fixed at 32 bytes, so the read call should return 32 bytes even if the payload of the header is smaller. - could we put it the header in /sys/firmware/dmi/raw/header perhaps?
Thanks, Ard.