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 havefixed biosesquoted
have a way to let customers find this out without bitchingat 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