RE: RE: ACPI -- Workaround for broken DSDT

On Mon, 2004-02-09 at 15:29, Nate Lawson wrote:

On Wed, 4 Feb 2004, Scott T. Smith wrote:

quoted

On Wed, 2004-02-04 at 21:15, Brown, Len wrote:

quoted

Windows doesn't have to do anything.  By being first to ship ACPI, that
implementation provided the defacto ACPI compliance test to which all
BIOS' are tested -- even if that implementation is not ACPI spec
compliant.  No, only under dire circumstances will we emulate Windows
bugs in Linux.

So basically we shouldn't use ACPI then, and instead use APM?

If Linux ACPI could emulate the bugs that Windows has, then ACPI would
work on Linux on most platforms right away.  That would make Linux more
accessible to people.  Linux already has a bunch of hacks to support
broken hardware which presumably Windows can work around; this seems to
be just another one of those.

We're doing something slightly different with ACPI on FreeBSD.  We add
hacks^Wworkarounds for buggy DSDT whenever possible but they are under a
kernel option, #ifndef ACPICA_PEDANTIC.  The default is for this option to
give maximum compatibility with the stock DSDT, at the expense of spec
correctness.  However, by adding that option and compiling a kernel, OEMs
could test against ACPI-CA as a reference implementation while ordinary
users get maximum compatibility.

I think the ACPI-CA developers should take a similar tact.  Len, who is on
the Linux side, could suggest distribution maintainers use the option that
gives maximum Windows compatibility when shipping a distro.  Bob, who is
on the ACPI-CA side, could encourage OEMs to test with the option
disabled.  It might even make sense for a Linux distro maintainer to
partner with ACPI-CA to provide a reference ISO that OEMs could boot that
had a /sbin/init that tests the various APIs for correctness.  Both Andy
and I thought this was a good direction to go and perhaps people are
already making progress in that area.

I agree 100% with this strategy, Nate.  The users and the OSDs just want
it to work.  The OEMs should have an option to make it into a better
platform test.  Based on the questions I get today, educating the OEMs
to use something other than the stock distro off the shelf, however, is
harder than you might think.  Maybe having the dedicated test ISO is a
good idea.  We'd discussed this in the past, and one benefit is that it
would never be confused with the distro.

Mgr: Did the Linux ACPI Compliance test pass?
Tester: Yes, we booted Red Hat, SuSE, etc
Mgr: No, I said the Linux-based ACPI Compliance Test...

This strategy, however is not incomplete.  The Linux OSDs need to sign
up as ACPI Adopters.  Linux OSDs should have both advanced knowledge and
direct impact on what is being written into the ACPI spec.  Today they
have neither.

-Len




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn