On 21 January 2015 at 11:53, Ivan Khoronzhuk ivan.khoronzhuk@linaro.org wrote:
On 01/21/2015 11:18 AM, Ard Biesheuvel wrote:
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
Ok.
- move the create_bin_file call to after dmi_walk() so that it
instantiates the sysfs entry only if (dmi_available)
yes.
- use __BIN_ATTR_RO() instead of opencoding the struct initializers
In this case the following question will be reasonable: why we have different modes for "raw" attributes from entries kset and for "smbios_raw". __BIN_ATTR_RO assigns 0444.
Ah ok, I didn't notice that. I think 0400 is preferable.
- 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.
Let it be.
Ehm, no
If stat() returns a file size of 32 bytes, read() should produce 32 bytes worth of data
You could drop the const from the struct bin_attribute and set the filesize dynamically if you like
PS: paranoid thought: ... return redundant data from kernel (security... who knows in what way it can be used)
Well, a static char[32] will be zero initialized, so if you make sure you don't memcpy() more that you need, we'll be fine.
- could we put it the header in /sys/firmware/dmi/raw/header perhaps?
In this case we need to create kset then attribute w/o visible reason. It be justified if we create smth like ./dmi/smbios/raw and ./dmi/smbios/version but currently I don't see reasons for that.
OK fair enough. Could we at least put 'header' in the name? 'smbios_raw" suggests it is the whole table.