[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dmidecode] non-dmi compliant systems
From: |
Jean Delvare |
Subject: |
Re: [dmidecode] non-dmi compliant systems |
Date: |
Mon, 11 Apr 2016 21:54:36 +0200 |
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