Stackable dmi_blacklist rules
RFC PATCH 1/1 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
Quoted 3 lines
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.
Hardly. You can set it back, you can also access the fields to make complex decisions after a match call.
Quoted 6 lines
Quoted 3 lines
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.
Hardly. You can set it back, you can also access the fields to make complex decisions after a match call.
You'd have to write extra feature_off callback functions, though (or change the existing ones, as I did), since currently no callback function allows to reset a value once it was called. They are all coded like this:
static __init int apm_is_horked(struct dmi_blacklist *d)
{
if (apm_info.disabled == 0)
apm_info.disabled = 1;
printk(KERN_INFO "%s machine detected. Disabling APM.\n", d->ident);
return 0;
}What I was looking for was a solution which allows resetting values simply by changing the dmi_blacklist.
One can of course argue that we can always add apm_is_not_horked_after_all() should the need ever arise.
Roger Luethi