On 07.01.2010 15:47, Luc Verhaegen wrote:
On Thu, Jan 07, 2010 at 03:37:04PM +0100, Carl-Daniel Hailfinger wrote:
On 07.01.2010 11:16, Michael Karcher wrote:
That's what I expected, and that's why I didn't commit yet. I won't commit until you and Carl-Daniel agree on the necessity of providing which string to match, although I slightly prefer the explicit specification of the string to match.
The explicit string match has the advantage of being extensible. More below.
Looking at the Asus P5A example (I know that this board is severly outdated, which might make this point less strong) there are no subsystem IDs at all in it. So when we start looking for DMI info we don't have any indication yet that we are on an Asus board. If we really have good subsystem IDs, we don't need DMI.
Yes. And in case we ever want to match two strings at once, the "bp:^A8V MX$" can be extended easily to "bvbp:^ASUS$:^A8V MX$" without changing any structs at all. Especially in the case where there is no usable PCI subsystem ID (board vendor not present) this may come handy. I'd wait for such an extension until we really desperately need it, though.
From some previous mail:
I don't think we need the "any:" prefix (I think I would have written it as "??:") at all. The match-any policy was in just to shorten the table entry.
This whole thing is why i was initially very weary of *^$ in these strings. People end up trying to go beyond when they see something like that, it's something psychological that i have seen at play more often in these cases.
Ah, I understood "go beyond" as trying to use unsupported regexps, which will be caught during review. My extensibility point was about not having to mess with the whole table each time we need changes in the DMI match policy.
Regards, Carl-Daniel