Re: DSDT in initrd

["Randy.Dunlap" <rddunlap-3NddpPZAyC0@public.gmane.org>]

On Fri, 16 May 2003 15:50:40 -0700 "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

| > From: Michael Frank [mailto:mflt1-DTdK3Ks6N5kHTnRCetW4+N0b+6lKrnBL@public.gmane.org] 
| > On Friday 16 May 2003 09:41, Brown, Len wrote:
| > > > IMHO this patch is very useful because it provides the
| > > > equivalent of a "DSDT module" and avoids building a kernel
| > > > for each DSDT.
| > >
| > > This is the 1st reason I've seen for not simply using an
| > > ACPI_DSDT_OVERRIDE config option to pull a DSDT into the kernel
| > > from a well-known file name.
| > 
| > DSDT problems will be around for a long time as this 
| > technology makes it into the main stream, while still maturing.
| > 
| > For example: I found DSDT of a recent P4 mainboard has 16 
| > compile errors. 
| > 
| > Realistically, one can't go really into production with it 
| > without being able to override.
| 
| 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.
| 
| 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. If there are bugs in the DSDT, we need to get on OEMs to fix them.
| 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.
| 
| 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!) but this skill is the equivalent
| of requiring someone to know how an engine works in order to drive a
| car.

Well I kinda like this patch, but then I'm not a normal Linux user.  :)

Lots of newer systems don't have an option of "... safely reverts to
non-ACPI ...", and surely you know that.  It's make ACPI work in some
fashion or have no power management.

It seems that your goal is idealistic and not user-friendly, at least
not in the short-term.  It's a worthy long-term goal.

The ACPI interpreter will always have bugs in it.  The BIOS DSDTs
will always have bugs.  After all, they are software (or firmware).

--
~Randy


-------------------------------------------------------
This SF.net email is sponsored by: 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