All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.