Re: [dmidecode] non-dmi compliant systems

[Jean Delvare]

On lun., 2016-04-04 at 13:33 +0100, Eric Saint-Etienne wrote:
> 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 

You are mixing two completely different things here. Portability of a
language has nothing to do with portability - desired or effective - of
programs written in said language.

> are present, then meaningful data will be extracted and returned by 
> python-dmidecode. Otherwise python-dmidecode should not return anything.

This is one possible way to implement it. But that's not the smartest
one IMVHO, see below.

> 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.

This is a mess I don't want to be involved in. dmidecode isn't a library
and shouldn't be used as one. There is libsmbios for that.

> The integration flow {dmidecode -> python-dmidecode -> arch-agnostic 
> diagnostic software} is not always controllable and I can see two options:

You are again mixing different things. You first "->" is source code
copy and wrapping up, while the second "->" is one piece of software
calling another, unrelated and independent piece of software.

>      - 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,

I very much hope it is the only one. One is one too much already as far
as I am concerned.

>  so that making dmidecode safer benefits to a larger scope of 
> middlewares and diagnostic programs.
>      - dmidecode-python would have to patch every rebase.

They already do exactly that. A little more, I can't see how that would
bother them.

Anyway I don't think the "fix" belongs to either dmidecode or
python-dmidecode. It belongs to whoever calls python-dmidecode. That
piece of software (you still did not tell us what it was?) should simply
be able to cope with python-dmidecode being absent on architectures
where it is not relevant. This is by far the most simple and optimal way
to solve your problem.

Once again, building dmidecode or python-dmidecode on architectures that
do not implement SMBIOS, for the sole purpose of them doing nothing
successfully, is a waste of time and energy. If you really want to do
that, just do:

# ln -s /usr/bin/false /usr/sbin/dmidecode
# ln -s /usr/bin/false /usr/sbin/python-dmidecode

(or /usr/bin/true, you decide.) Here, problem solved.

-- 
Jean Delvare
SUSE L3 Support