[flashrom] DMI matching patch

[Luc Verhaegen]

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:
> >
> > 1)
> >
> > 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.

> > 2)
> >
> > 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.
> 
> 
> > 3)
> >
> > 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.