RE: ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround forbroken DSDT)

[Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

You must have something specific in mind, b/c I have a more
simple-minded view.  There are two modes

1. default
all workarounds in place (there actually are not very many)
minimum pedantic warnings
users and distros expected to use this mode

2. acpi=strict
all workarounds excluded
maximum pedantic warnings
OEMs, testers, and ACPI developers expected to use this mode.

This is selected at run-time by absence or presence of acpi=strict.
If there is a case where something can't really can't be turned on and
off at run time (the case you're worrying about), then we simply leave
it the way it is now -- always on.

On Thu, 2004-02-12 at 01:32, Yu, Luming wrote:
> 1. A kernel option such as ACPI_STRICT=ON will mess up ACPI CA code at
> run-time.
> For example, a small change to ACPI interpreter without strict
> regression test could break
> other part of ASL codes wich comply to ACPI spec. 

The only regression test we us today is to ship changes to the community
and see if systems run better or run worse.  I don't see this changing.

> 2. How to coordinate various workarounds which could be conflicted with
> each other?

exactly the same way we do today.




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click