Re: [dmidecode] non-dmi compliant systems

[Eric Saint-Etienne]

Hi Jean,

On 04/04/16 10:26, Jean Delvare wrote:
> Hello Eric,
>
> I'm confused. What is the point of building dmidecode (or
> python-dmidecode for that matter) for systems which do not support DMI
> in the first place?
I see what you mean, but keep in mind that dmidecode ends up being 
called by softwares that are architecture agnostic, to gather 
information about the system.
In the occurence I'm concerned with, this high level architecture 
agnostic software is written in Python, which is a "portable" 
language/platform, so it's fair for this software to make use of 
python-dmidecode irrespectively of the architecture: if the DMI tables 
are present, then meaningful data will be extracted and returned by 
python-dmidecode. Otherwise python-dmidecode should not return anything.

At the moment, python-dmidecode acts as a mere wrapper around dmidecode 
C functions. The maintainer regularly rebases upon earlier versions of 
dmidecode sources that gets included verbatim into github 
python-dmidecode repo.

The integration flow {dmidecode -> python-dmidecode -> arch-agnostic 
diagnostic software} is not always controllable and I can see two options:
    - a guard rail in the midlleware python-dmidecode
    - or directly in dmidecode.

To me it makes sense to make dmidecode safer for the following reasons:
    - the middleware may not be the only one to include dmidecode 
sources, so that making dmidecode safer benefits to a larger scope of 
middlewares and diagnostic programs.
    - dmidecode-python would have to patch every rebase.

Kind Regards,
Eric