ACPI black-list (was RE: Working around bugs in ACPI BIOS [was Re : DSDT in initrd])

From: Brown, Len <hidden>
Date: 2003-05-27 18:28:14

quoted
A please upgrade signature table so that vendors who have 
fixed bioses
quoted
have a way to let customers find this out without bitching 
at support

Yeah.
I like this too.  If somebody hasn't done it already I volunteer to take a
swing at it.

This sort of leads to examination of the ACPI black-list scheme -- which I
think needs some work.

It should have a cut-off date for each vendor, with a black list disabling
ACPI on platforms newer than that date, plus a white list enabling ACPI for
platforms older than the cutoff date.  If the OEM isn't on the list, there
should be a default cut-off date.  If the date is about in the right place,
then the black and white lists will be short. 

Also, the current black list has 3 possible outcomes:
1. pass black list and continue with everythything enabled.
2. fail black list, print a warning, but continue with acpi anyway ("non
critical")
3. fail black list, and disable ACPI.

Option 2 is worthless.  Probably better would be some flag bits that disable
the part of ACPI that actually fails -- leaving the rest intact.  (eg. Just
because fan speed adjustment has a bug doesn't meen that power states have
to be disabled).

I think if we do this, then it will be easier to deploy and support
ACPI-enabled systems, and less necessary for hackers to enhance their DSDT
just to make their sytem function.

Cheers,
-Len


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help