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
_______________________________________________
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
