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 years.
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.
Right.
- Even then a very large proportion of the boards is and will be happy with just pci subsystem ids.
Right.
- 10-20% will be happy with pciids or pci subsystem ids and a simple DMI match.
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 -m.
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.
Fully agreed.
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.
To summarize: - 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.
Regards, Carl-Daniel