Re: [dmidecode] /sys/firmware interface?

[David Sommerseth]

On 05/02/15 12:11, Leif Lindholm wrote:
>>> (And /sys/firmware/acpi for ACPI.)
>>
>> Not sure why you mention that, as dmidecode doesn't care about ACPI at
>> all?
> 
> Purely for context. Not suggesting ACPI is relevant to dmidecode.
> 
> On ARM systems, without a predictable physical memory map, directly
> using /dev/mem is a _really_ bad idea - so at least for ARM server
> systems, we need to get to the point where we can shut /dev/mem off
> completely.

+1

>>> Looking around, I find at least several (possibly many) projects doing
>>> /dev/mem scanning for DMI/SMBIOS. If DMI_SYSFS is an acceptable way to
>>> go, would anyone object to it being an external library as opposed to
>>> part directly of this project?
>>
>> The sole fact that you think it would require a library to
>> make /sys/firmware/dmi usable by user-space tools is IMHO a good hint
>> that the interface is screwed up.
> 
> The library is not suggested because of some massive complexity, but
> to be able to reuse the code in many existing software packages.
> dmidecode is currently safe on x86, EFI systems with SMBIOS, and
> unsafe on any other system. This is a lot better than the average
> package out there.

As one of the maintainers of python-dmidecode, I'd welcome a library to
do this decoding very much.  It would simplify a lot for us.

I did suggest using a library approach several years ago, and it was
shut down instantly without any other reason to keep dmidecode as simple
as possible.  While I do appreciate code being as simple as possible, I
do not think it is a valid argument if others can reuse the same code
more efficiently.  Yes, libsmbios and similar libraries exists, but
those libraries just do so much more than just this simple decoding
which is what python-dmidecode needs.  Again, I prefer simplicity.  But
on the other hand, a massive porting effort is now needed to keep
python-dmidecode aligned with the decoding level of dmidecode.

So if there is enough momentum to go towards a library model for just
decoding DMI data, I will definitely support that.  A port of a next
generation python-dmidecode won't be that far behind.


--
kind regards,

David Sommerseth