On Mar 3, 2009, at 4:14 PM, Mike Shapiro wrote:
Argh, SMBIOS. There are two issues I have with heavily relying on
SMBIOS:
1) A given system's SMBIOS accuracy and completeness (read: quality)
can vary wildly from vendor to vendor and even within a single
vendor's product line. This is the biggest problem with SMBIOS, I
think. I've seen systems that don't register PCI slots as occupied,
when they are, and others that don't populate memory slot information
such as DIMM vendor IDs and serial numbers.
We know that, but it's irrelevant. *Any* data format we pick
can be implemented correctly or not. All Sun can do is pick
something and ensure that for its own hardware we do it right.
Everyone else has to make sure their h/w and s/w match up.
My sentiments as well, but the doubt I aired is the "Everyone else has
to make sure their h/w and s/w match up" part :) Call me pessimistic,
given how some vendors are lackadaisical with the current way they
ship SMBIOS on their boxen. I hope vendors take it more seriously in
the future, though.
2) Aside from the general issue of having to chase the DMTF SMBIOS
spec whenever it's rev'd, Solaris's smbios(7d) driver isn't currently
the best w.r.t. decoding the whole of a given system's SMBIOS
structures. I had a putback last year to bring it up to speed w.r.t.
ID'ing newer RAM and CPU types, but there are still yet whole
structures defined in SMBIOS 2.5 and 2.6 which aren't known to
smbios(7d). Is there a RFE to address this if SMBIOS is going to be
leaned on further?
The SMBIOS driver doesn't decode the data, the SMBIOS library does.
The library supports a certain set of things I decided were useful
when I wrote it. Any other structures that are useful can be added.
Ah yes, that's a brain fart on my part... I should have known better,
as I have some code in libsmbios now. I chalk this up to "too many
subsystems to keep track of" ;)
Also we're not talking about SMBIOS exclusively. For example
CPUs are primarily identified by other means -- the only use of SMBIOS
for CPUs is the socket *label*, which is not available anywhere else.
Understood.
One other thing I wonder, is how or if any info can be reconciled
between a system's BMC and its SMBIOS repository. Will there be the
necessary smarts to correlate, say, DIMM CE alerts from a system's
SEL
with the correct SMBIOS Physical Memory Array structure its related
to?
One has to have some means of indexing from one to the other:
for example an IPMI path or an APIC ID or whatever is appropriate.
The major issue with SMBIOS today is that for things for which it
is appropriate there is often not a way to correlate accurately:
we are endeavoring to make some changes to fix that.
I'm interested in learning more about this. I know that Sun hasn't
been a contributing party to the DMTF SMBIOS spec in the past (Dell
and Intel thus far being the major contributors.) Are there plans
around Sun becoming a presence there now with the FMA plans that are
afoot?
/dale
_______________________________________________
fm-discuss mailing list
fm-discuss@opensolaris.org
