From: "Scott T. Smith" <scott-j3vAvQ9dNB9ByuSxxbvQtw@public.gmane.org>
To: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: RE: ACPI -- Workaround for broken DSDT
Date: Wed, 04 Feb 2004 22:55:49 -0800 [thread overview]
Message-ID: <1075964148.5017.7.camel@tinny.home.foo> (raw)
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE0CC8AB6-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
On Wed, 2004-02-04 at 21:15, Brown, Len wrote:
> The strategy is to improve ACPI on Linux such that all Linux distros are
> able to successfully ship ACPI enabled kernels.
>
> When we reach that stage, the OEMs will use these commercial Linux
> products when they validate their platforms -- fixing DSDT problems
> themselves before the 1st BIOS is released to the public.
realistically, that's 3-5+ years away. In the meantime, what are
existing users to do? (i.e. those of us who don't like reading 430+
pages of the spec)
> 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.
While it would be great if BIOS' used correct DSDT's, then what would
happen if those DSDT's didn't work on Windows? Which version do you
think they'd ship? Methinks not the one that works on Linux.
OTOH, what happens when Microsoft tries to fix their existing bugs --
they'll either stick with their buggy version forever, or have to
support several versions, depending on how many bugs are fixed and when
they are fixed. Or you'll end up with some versions of Windows that
won't run on older or newer laptops.
Seems like a messy situation, any way you look at it.
Scott
-------------------------------------------------------
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
next prev parent reply other threads:[~2004-02-05 6:55 UTC|newest]
Thread overview: 26+ 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 [this message]
[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 ` ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround for broken DSDT) Len Brown
[not found] ` <1076517428.12955.32.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-11 17:51 ` 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
-- strict thread matches above, loose matches on Subject: below --
2004-02-11 6:31 Yu, Luming
2004-02-05 14:33 Cagle, John (ISS-Houston)
[not found] ` <C50AB9511EE59B49B2A503CB7AE1ABD1066111ED-Iar2LzuD2f6P0FQRY6S+e9kSKC0Mw0DFJ8am2ALHCgk@public.gmane.org>
2004-02-05 15:19 ` Andi Kleen
[not found] ` <20040205161923.37eebc64.ak-l3A5Bk7waGM@public.gmane.org>
2004-02-05 16:07 ` Bas Mevissen
[not found] ` <40226A58.5080004-Y9IUUvl1dgU0Iwp8Nzs06g@public.gmane.org>
2004-02-05 16:24 ` Andi Kleen
[not found] ` <20040205172405.01777986.ak-l3A5Bk7waGM@public.gmane.org>
2004-02-05 17:15 ` Bas Mevissen
2004-02-05 15:55 ` Bas Mevissen
2004-02-06 19:33 ` Bruno Ducrot
2004-02-05 8:10 Brown, Len
[not found] ` <BF1FE1855350A0479097B3A0D2A80EE0CC8AB9-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2004-02-05 8:58 ` Luca Capello
[not found] ` <402205B0.3000607-wlebWZzHoyE@public.gmane.org>
2004-02-05 22:43 ` Karol Kozimor
2004-02-05 15:44 ` Scott T. Smith
[not found] ` <1075995857.5758.43.camel-3lu5YwujmwObGSPjaX/RoA@public.gmane.org>
2004-02-05 16:13 ` Bas Mevissen
2004-02-04 7:22 Brown, Len
[not found] ` <BF1FE1855350A0479097B3A0D2A80EE0CC8A9F-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2004-02-04 7:49 ` Arjen Verweij
2004-02-05 2:18 ` Scott T. Smith
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=1075964148.5017.7.camel@tinny.home.foo \
--to=scott-j3vavq9dnb9byusxxbvqtw@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@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