On 07.01.2010 11:13, Luc Verhaegen wrote:
On Fri, Jan 01, 2010 at 01:27:44AM +0100, Michael Karcher wrote:
I believe the substring match is suboptimal.
You got a point there.
I wouldn't use any word related to optimal in relationship to the board enable table.
Heh. I tried to be polite.
I would like to see a single string match, because this maximalises our effectivity, while minimising the impact on our already large board enable table.
That being said, sticking the dmi substring selection in the matching string, is contrived and will only lead to problems. If this really is what is wanted, then please use an enum.
The enum will clutter up the table a lot more than 3 chars at the beginning of the DMI string, so I'd rather avoid it.
But for the time being, i believe that it is not needed. And it can be added easily later on if we start collecting dmi info.
We really need a database of all that stuff (DMI, PCIID, SuperIO) and not only something googleable. If google indexes the database, yay for us, but the ability to do systematic data mining does make stuff a lot easier.
I'd make that warning conditional on the absence of a coreboot table. Otherwise you'll get a warning on a lot of systems with coreboot.
You will only get that warning if the PCI IDs match and the DMI is missing. When you run on coreboot, you don't even get into board_match_pci_card_ids(), as board_match_coreboot_name() already has chosen the right board.
Sounds all good.
The matching functions is also still on my todo list. Splitting the matching functions from two (named/coreboot, pciid) into three (coreboot, named, pciid), to tighten up the board enable table.
Sorry, -ENOPARSE.
Regards, Carl-Daniel