public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org>
Cc: "Scott T. Smith" <scott-j3vAvQ9dNB9ByuSxxbvQtw@public.gmane.org>,
	ACPI Developers
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	Robert Moore
	<robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Andrew Grover
	<andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround for broken DSDT)
Date: 11 Feb 2004 11:37:08 -0500	[thread overview]
Message-ID: <1076517428.12955.32.camel@dhcppc4> (raw)
In-Reply-To: <20040209122256.K74314-Y6VGUYTwhu0@public.gmane.org>

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

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

Nate,
I think you're right, practical compatibility must be the default, and a
single config option should allow an OEM to disable the out-of-spec
warnings and workarounds.

CONFIG_ACPI_STRICT_COMPLIANCE seems to be a good choice for the config
option.  Disabled by default, enabled by OEMs for testing their
platforms.

Right now, CONFIG_ACPI_RELAXED AML would be replaced by this.  This will
fix the issue that RELAXED_AML is not currently enabled by default.

We have some warnings and workarounds that gum-up various dmesg that I
think we can put under this umbrella also.

thanks,
-Len




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

  parent reply	other threads:[~2004-02-11 16:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-05  5:15 RE: ACPI -- Workaround for broken DSDT Brown, Len
     [not found] ` <BF1FE1855350A0479097B3A0D2A80EE0CC8AB6-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2004-02-05  6:55   ` Scott T. Smith
     [not found]     ` <1075964148.5017.7.camel-3lu5YwujmwObGSPjaX/RoA@public.gmane.org>
2004-02-05 10:00       ` Bruno Ducrot
2004-02-09 20:29       ` Nate Lawson
     [not found]         ` <20040209122256.K74314-Y6VGUYTwhu0@public.gmane.org>
2004-02-09 21:23           ` Len Brown
2004-02-11 16:37           ` Len Brown [this message]
     [not found]             ` <1076517428.12955.32.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-11 17:51               ` ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround for broken DSDT) Nate Lawson
2004-02-12 10:19           ` RE: ACPI -- Workaround for broken DSDT Bruno Ducrot
2004-02-05  7:29   ` Andi Kleen
     [not found]     ` <20040205082926.660974d2.ak-l3A5Bk7waGM@public.gmane.org>
2004-02-05 12:09       ` Bas Mevissen
2004-02-05 11:34   ` Bas Mevissen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1076517428.12955.32.camel@dhcppc4 \
    --to=len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=nate-Y6VGUYTwhu0@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=scott-j3vAvQ9dNB9ByuSxxbvQtw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox