Am 23.12.23 um 11:18 schrieb Jean Delvare:
Hallo Armin,
On Tue, 19 Dec 2023 20:27:23 +0100, Armin Wolf wrote:
Am 19.12.23 um 12:01 schrieb Jean Delvare:
If we are going to print raw data then it should be formatted better,
one number per line is taking way too much space. But see below.
I understand, is there a standard function for dumping binary data?
Nothing that can be called immediately, however we have function
dmi_dump() which prints raw record data. It should be possible to split
a utility function out of it, and reuse it elsewhere.
That being said... I'm not convinced that it makes sense to print such
raw data in the first place. The whole point of dmidecode is to...
well, decode the data. If we aren't able to do that, I'd rather not
print anything. Users who really want to see the raw data can already
get it with "dmidecode -u".
(...)
I just can't see how adding this to the output of dmidecode is helpful.
As long as we don't know the meaning of the data block, I'd rather not
decode type 44 at all.
The format of this data block is documented for RISC-V and LoongArch,
Do you have links to these documents?
and for the last we can access such SMBIOS data:
https://linux-hardware.org/?probe=97348ef480
OK, it would be great if someone can get a copy of the DMI table
itself, instead of just the output of dmidecode.
I could implement decoding of the data block for this architecture,
but not for RISC-V (i have not found any RISC-V SMBIOS dumps online).
Would this be a good reason to add support for type 44 entries?
Yes, if we can decode that type for at least one architecture, then it
makes sense to add support for it.
Thanks,
Well, i was unable to get my hands on a copy of a LoongArch DMI table for
testing.
Maybe we can add support for type 44 entries later.
Armin Wolf