public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Zoz <zoz-l3A5Bk7waGM@public.gmane.org>
To: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
Subject: Re: DSDT in initrd
Date: Tue, 20 May 2003 17:37:54 +0200	[thread overview]
Message-ID: <20030520153754.GG24453@suse.de> (raw)
In-Reply-To: <F760B14C9561B941B89469F59BA3A84725A2A7-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>

On Fri, May 16, Grover, Andrew wrote:
> 
> It should be obvious that using DSDT override (however easy we make it)
> is NOT an option for distributions or any sort of non-developer
> solution. You mention that distributions could install DSDTs on
> installation but I don't buy it. This is part of the reason that I
> haven't been very receptive towards making DSDT override very easy.

Distributors cannot ship fixed DSDTs. That would be to much work. But
there are a lot of Linux Newbies with a laptop that worked so far with
W*. Now they are going to try Linux and get ACPI troubles.
It's far easier to explain them to place a fixed DSDT in a certain
file and to call mkinitrd than to guide them trough a kernel
complilation and installation.
Life would be ways easier for supporters. 

There are people wich benefit from this patch.
Does this patch harm on the other side?

> We need to look for solutions that make using an ACPI-enabled kernel
> possible on the widest number of machines possible, *without* involving
> DSDT override. If there are bugs in the interpreter, we need to fix
> them.

Yes.

> If there are bugs in the DSDT, we need to get on OEMs to fix them.

Yes.

> Or, we need to have a blacklist that, either via specific system
> signatures or just BIOS date, safely reverts to non-ACPI on machines on
> which it has problems.

You cannot always revert to non-ACPI without losing funcionality.

At this point the average private laptop user is left alone. Why don't
we help him to fix his buggy DSDT?

> I really think it's kind of funny that so many people on this mailing
> list have gotten so good at fixing their systems' DSDT (maybe they
> should apply for BIOS engineer jobs!)

Wonderfull! This maybe helps to come to more sophisticated BIOS
engineer and thus better BIOSs. ;)))

> but this skill is the equivalent of requiring someone to know how an
> engine works in order to drive a car.

Sometimes i were glad i could fix the programming of my bordcomputer
myself.

-- 

ciao, christian

  --------------------------------------------------------------------
    Verglichen mit jedem x-beliebigen Redmonder Betriebssystem-Clone
    ist Linux geradezu eine leuchtende Perle der Datensicherheit.
  ------ Frank Rennemann (http://www.linux-knowledge-portal.org) -----


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

  parent reply	other threads:[~2003-05-20 15:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-16 22:50 DSDT in initrd Grover, Andrew
     [not found] ` <F760B14C9561B941B89469F59BA3A84725A2A7-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-05-16 23:04   ` Randy.Dunlap
2003-05-17  9:30   ` Markus Gaugusch
2003-05-20 15:37   ` Christian Zoz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-19 14:38 Brown, Len
     [not found] ` <A5974D8E5F98D511BB910002A50A6647054FC40A-MgY+aF+eRfZviC08c4yzC1DQ4js95KgL@public.gmane.org>
2003-05-19 14:53   ` Ducrot Bruno
2003-05-19 15:26   ` Michael Frank
2003-05-20 16:56   ` Markus Gaugusch
     [not found]     ` <Pine.LNX.4.53.0305191725350.9728-sxQ525G0OhRQK2oVCIMtW7NldLUNz+W/@public.gmane.org>
2003-05-20 18:01       ` Matthew Wilcox
     [not found]         ` <20030520180149.GJ31518-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>
2003-05-20 18:03           ` Markus Gaugusch
2003-05-21  7:23             ` Nathan Gray
2003-05-17  1:17 Grover, Andrew
     [not found] ` <F760B14C9561B941B89469F59BA3A847E96EA0-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-05-18 20:07   ` Mark Santcroos
     [not found]     ` <20030518200724.GB631-ScjxTogt4I4lGuH5DXb43w@public.gmane.org>
2003-05-19 10:10       ` Adachi, Kenichi
2003-05-16  1:41 Brown, Len
     [not found] ` <A5974D8E5F98D511BB910002A50A6647054FC400-MgY+aF+eRfZviC08c4yzC1DQ4js95KgL@public.gmane.org>
2003-05-16  5:58   ` Markus Gaugusch
2003-05-16  6:24   ` Michael Frank
2003-05-13  4:28 Michael Frank

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=20030520153754.GG24453@suse.de \
    --to=zoz-l3a5bk7wagm@public.gmane.org \
    --cc=acpi-devel-pyega4qmqnRoyOMFzWx49A@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