Re: [dmidecode] dmidecode dumps as test cases?

[Jean Delvare]

Hi Bastien,

On Sat, 14 Nov 2020 15:27:55 +0100, Bastien Nocera wrote:
> I'm slowly mangling a version of dmidecode to extract only the memory
> module related information:
> https://github.com/hadess/udev-memory-devices
> which I hope to merge into udev:
> https://github.com/systemd/systemd/issues/16651

Sounds like a bad idea. Duplicating code in a different project means
you'll have to maintain it in parallel forever, for both bug fixes and
changes requested by the SMBIOS specification updates. I think it would
be preferable to implement whatever you need either in dmidecode or
directly in the kernel.

Can you please describe your actual needs?

> I was wondering whether there was some place I could get a bunch of
> "dmidecode --dump-bin" outputs to test this against, in particular ones
> with handle types 5 and 6. Or are those handle types too old to bother?

I don't know of any public repository of these. I do have a nice
private collection, but am reluctant to share it as-is because DMI data
contains sensitive data. I can check what I have with types 5 and 6 and
clear the sensitive data before sending them to you, but this is all
manual so it will take some time.

Alternatively I could simply perform the tests myself.

That being said, I don't know how critical your functionality is, but
if it's only "nice to have" then I would just ignore types 5 and 6. I
only have 4 samples where these types are implemented and type 17
isn't, and these are SMBIOS 2.0, 2.1 and 2.2 implementations. Types 5
and 6 were deprecated by SMBIOS 2.1. I don't know the exact date
but it was probably around 1997. All of these machines have been
decommissioned long ago.

-- 
Jean Delvare
SUSE L3 Support