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/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:57 EST