[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] non-dmi compliant systems

From: Eric Saint-Etienne
Subject: Re: [dmidecode] non-dmi compliant systems
Date: Mon, 4 Apr 2016 13:33:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]