Messages in this thread | | | Date | Thu, 23 Aug 2001 15:22:00 +0200 | From | Roger Luethi <> | Subject | [PATCH (URL), RFC] Stackable dmi_blacklist rules |
| |
Please Cc: me on replies as I'm not subscribed to lkml. I am interested in feedback on whether this is a track worth following. The actual patch will probably fail against anything but 2.4.8-ac9 anyway.
The dmi_blacklist has become pretty popular in a short time (two dozen entries as of 2.4.8-ac9). When I was about to write an entry for yet another Sony BIOS, I wondered if there was a way to make the system more flexible.
Currently, we walk the list and throw out bad apples based on full or partial strings we match against what we get from the BIOS. Once a rule matches, the value is immutable.
This prevents us from directly coding something like (fake examples):
- use fix for apm quirk on all Sony BIOS except BIOS R03 - disable IDE DMA for VIA but allow it for revisions which are known to be good
A possible solution would be to allow rules to override previous rules.
While stackable blacklist rules allow for shorter encoding of the same information, there is a potential for an improved development process that I consider equally important.
For instance, in order to reduce the exceedingly long list of Sony BIOSes we might as well blacklist them all and declare good whatever we find to work later.
Because the rules are walked in order, we could stack any number of them as long as we sorted them properly: the most specific rules would have to go to the end of the list.
What the patch does ------------------- The simple patch I wrote adds an integer field to struct dmi_blacklist which defines whether the rule will turn the specified flag on or off (all currently defined rules turn the flag on, obviously).
The callback functions were changed to reflect the new behavior. Basically, instead of saying "This is broken" they will say "Workaround: on" (or off, respectively).
For IDE DMA, I made sure that the blacklist never overrides the boot parameter (ide=nodma). The same could be done for other parameters as well, but this patch is a proof of concept at this stage.
The patch is against 2.4.8-ac9, the dmi_blacklist hunk is likely to fail with every other kernel (it's trivial to merge the rejected lines, though).
It is quite long (the dmi_blacklist table alone is over 150 lines) and I guess few people are interested in applying it right now anyway, so here's where to get it:
http://hellgate.ch/work/dmi_blacklist.diff
Roger Luethi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |