On Mon, Jan 04, 2010 at 06:10:51PM +0100, Michael Karcher wrote:
Am Montag, den 04.01.2010, 15:35 +0100 schrieb Luc Verhaegen:
Some extra info on dmi that not everyone is acutely aware of:
This is where the dmi standard came from: http://www.dmtf.org/standards/dmi/
What you can read there is:
"Due to the rapid advancement of DMTF technologies, such as CIM, the DMTF defined an "End of Life" process for its Desktop Management Interface (DMI), which ended March 31, 2005"
You are right, DMI is outdated. However that doesn't really affect us. DMI is a complicated bloated remote API to access lots of system information. It has been replaced by even more bloated and high-level APIs as CIM.
A small subset of the info DMI could retrieve is the system information provided by the BIOS. This information was provided by the "Desktop Management BIOS specification". This specification was renamed to "System Management BIOS specification" when it got part of the DMTF to show that it is only a piece that is needed to get DMI to work.
What dmidecode does is just a dump of the SMBIOS database. The name dmidecode is for historic reason, smbiosdecode would be more accurate. This database is standardized in the SMBIOS specification, which is still alive, see http://www.dmtf.org/standards/smbios/
The latest revision is v2.6.1 from April 2009.
Regards, Michael Karcher
I am not trying to keep dmi out of flashrom any more. Pciids solve 95% of our matches, we need to fill in the other 5%. Sadly, dmi, whatever its state, is our next best option.
I am just warning that dmi might not be as tight and enduring as many people think it is, and that therefor it should be used with some care.
Making a dmi string part of the matching algorithm seems necessary for some boards. But it should be pretty much last in precedence, and only as an expansion, a further possibility for board matching.
Also, i own Jetway mini-itx boards for which dmi will not change a thing (but luckily, they do not require a board enable).
Luc Verhaegen.