On Thu, Jan 07, 2010 at 05:25:32PM +0100, Carl-Daniel Hailfinger wrote:
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.
Yes, but compared to the DMI, pciids are cheap and easy.
- 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.
This is what we've established now. We now require dmidecode output on the ml, before coding up a board enable.
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.
This was not the point here, but let's dig out another example from another angle.
Let's think up a device, and fill out the strings we try to match:
DMI_SYS_VENDOR = ABC DMI_SYS_PRODUCT = XYZ DMI_SYS_VERSION = 1234 DMI_BB_VENDOR = ABC DMI_BB_PRODUCT = XYZ 123 DMI_BB_VERSION = 1234
Let's say there are multiple XYZ versions, that also require different board enables. And we need to match "XYZ 123" instead of just "XYZ". And then we can just as well state "^XYZ 123$", as we can "bv:^XYZ 123$".
What could require this string specific stuff, this example:
Two devices:
DMI_SYS_VENDOR = ABC DMI_SYS_PRODUCT = XYZ 123 DMI_SYS_VERSION = 1234 DMI_BB_VENDOR = ABC DMI_BB_PRODUCT = XYZ 123 (!) DMI_BB_VERSION = 1234
DMI_SYS_VENDOR = ABC DMI_SYS_PRODUCT = XYZ 123 DMI_SYS_VERSION = 1234 DMI_BB_VENDOR = ABC DMI_BB_PRODUCT = XYZ 124 (!) DMI_BB_VERSION = 1234
How likely is this? How likely is this _while_ they need a different board enable. (and do keep in mind the figures i tried to guess at in the last mail).
We are trying to design a highly complicated scheme here, before any such an issue ever occured, and even then, this issue will be in even less than the .15% margin guessed before.
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.
This pain was trying to find _any_ good lspci. When i could just google for "$vendor $board lspci -v" and got good matches straight away, i was a happy camper. Being able to google "site:flashrom.org $vendor $board" and immediately get the relevant info (or even better, just grep the relevant mbox), is really really nice and fast.
To summarize:
- Specifying more than one DMI string for one board is hopefully
something we will never have to do.
The chance that this improves our matching potential on any board, is minimal, as explained before. It only will bring us something in a single or some _very_ specific cases.
- Not specifying which DMI string to match will be painful in case we
ever have to adapt our DMI infrastructure.
No, i doubt this is true.
First, i severely doubt this will ever occur.
Then if it does, we can deal with it then (we sure as hell know how already, that part has been bashed to death). If it does happen, then we can easily state _ANY for the existing ones, as this will be the main case anyway. If we want this to be tighter than any, then we can easily grep through our mailboxes and find the real matches.
Pain factor: very limited. I believe that the pain factor is mostly here, in another (imho) useless discussion over attempting to overdesign something instead of dealing with the real issues.
Deal with the real issue today, and finish off matching the remaining 5-10% of boards we cannot match today but which we can match with general string searching. The specification of the string is going to be a real margin requirement, that will only help us in a infinitessial number of cases, at best.
As i know that the "fix the issue when it presents itself" reasoning will not work in this case, and i can try to come up with the logic behind things endlessly, or try to come up with figures, i fear that it will not help in any way.
Try to work with this: Do it the way i suggest, and then prove me wrong.
Prove to me that there are actually cases that require this, by real examples, by waiting for the relevant case (yes, singular, no typo) to turn up.
Then feel free to give me all sorts of crap (i'm good at dishing it out, and therefor I should be good at getting it too (when justified)). I know that you are not the kind to kick people up the rear for something they did or decided wrong. But here i instruct you to do so, as that's the deal i want to see here.
Prove me wrong in that this will occur first, and give me the crap that i am asking for, and then if you give me enough crap, then I'll find the time to prove that it is not that hard to fix up too :)
Luc Verhaegen.