[PATCH (URL), RFC] Stackable dmi_blacklist rules

[PATCH (URL), RFC] Stackable dmi_blacklist rules

[Roger Luethi]

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

Re: [PATCH (URL), RFC] Stackable dmi_blacklist rules

[Alan Cox]

> 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. 

Re: [PATCH (URL), RFC] Stackable dmi_blacklist rules

[Roger Luethi]

> > 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