[flashrom] DMI matching patch
c-d.hailfinger.devel.2006 at gmx.net
Thu Jan 7 17:25:32 CET 2010
On 07.01.2010 16:46, Luc Verhaegen wrote:
> I do not expect DMI many match policy changes.
> * We've been relatively happy with pci subsystem ids for close to three
Yes, but that isn't a match-any policy either. The subsystem ID in the
table must come from the same device as the main ID.
> * Our board enable table recently exploded, with the massive increase in
> flashrom uptake.
Yes, and I'm very happy about that.
> But expect 30-40% of the board enables to be dropped
> soon (it8705f, w83627thf and itspi will be moved out), which will
> equally reduce our need to add entries to this table in future.
> * Even then a very large proportion of the boards is and will be happy
> with just pci subsystem ids.
> * 10-20% will be happy with pciids or pci subsystem ids and a simple DMI
> A few percent, which we still have to encounter in our board enable
> table, will never be happy (like my jetway boards), and will always need
> The case where we need to match multiple strings just to be able to
> identify a board also needs to happen still.
OK, so let's archive all interesting DMI strings on the list so we can
investigate any overlaps that might happen in the future.
I would still like the match to be specific, though.
> Let us consider a board where subsystem ids are just copied from the
> main ids (which is an issue of the bios, as the pci device default
> might either be 0 or copied depending on implemention).
> Let's look at some use cases:
> 0x1234, 0x5678, 0x1234, 0x5678, 0x1234, 0x5679, 0x1234, 0x5679
> If 0x1234 is a popular manufacturer, and the 5678/5679 northbridge
> southbridge configuration is a popular product, then chances are that
> a few bad manufacturers really are this bad. But you will not find more
> than 2-3 vendors doing things this badly, at least not for the same
> chips. Chances are then very very high that the model name is unique, or
> that we can at least match the vendor.
Note that our current DMI policy allows only either a vendor match or a
board match, not both of them.
> If we have the following for board maker 0xABCD:
> 0x1234, 0x5678, 0xABCD, 0x5678, 0x1234, 0x5679, 0xABCD, 0x5679
> Then the match becomes a lot more unique already, and we should be able
> to easily get away with just the DMI product id.
> Even for a vendor who creates tons of boards with the same subsystem
> ids (and we know one which requires itspi a lot :)):
> 0x1234, 0x5678, 0xABCD, 0xEF12, 0x1234, 0x5679, 0xABCD, 0xEF12
> We can then try to use the DMI product to differentiate the boards
> further (when choosing different pciids doesn't work, often due to added
> raid or gigE, that is). Here the string wildcard matching will help us
> out a lot, while the string selection will not.
> This pretty much maps all three situations, and a combination thereof
> seems possible.
> Now go back and try to see what "bvbp:^DEVICE$:^PRODUCT$" will gain us
> on top.
> My current answer to this: not much.
Yes, the multi-match with "bvbp:foo:bar" is something I do not want
supported in current code. It may be useful sometime in the future, but
for now I want to avoid such matches (and we seem to agree here).
> Let's just see how it works out with simple matching with wildcards.
> We will be collecting the data, and when needed, when a valid case
> turns up, we can expand.
Do you remember the pain you felt when going through old board enables
which had missing subsystem IDs because back then people didn't
care/know? Sure, there's always the possibility to dig through the
mailing list archives, but it is rather painful. By specifying the
string to be matched, I hope to avoid such pains in the future.
- Specifying more than one DMI string for one board is hopefully
something we will never have to do.
- Not specifying which DMI string to match will be painful in case we
ever have to adapt our DMI infrastructure.
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."
More information about the flashrom