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: > > 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. > 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. 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 -- Developer quote of the year: "We are juggling too many chainsaws and flaming arrows and tigers." _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
