[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, 04 Apr 2016 11:26:13 +0200 |
Hello Eric,
Le Friday 01 April 2016 à 09:25 +0100, Eric Saint-Etienne a écrit :
> Hi,
>
> It appears that dmidecode can be called on systems that do not contain
> DMI tables. For instance the python-dmidecode module, often used to get
> system information, includes dmidecode sources, verbatim.
> Programs that collect system information using python-dmidecode work
> fine on x86 compatible systems, but on machines such as SPARC, it simply
> makes cPython seg-fault when accessing non-existent DMI tables via mmap().
>
> I'm only concerned with the SPARC case (no other arch has shout as of
> yet) and I've got a patch for an older version of dmidecode that
> prevents from accessing DMI tables on the SPARC architecture. It's
> basically a bunch of conditional compilation around accessing DMI tables.
>
> If you find that using #if...#else at the right places an acceptable
> guard-rail, I'll then submit to this list a patch for the master branch.
>
> When the patch will be in, other architectures/systems that don't
> support DMI tables (ARM?, MIPS?...) could be easily added.
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?
--
Jean Delvare
SUSE L3 Support