From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Randy.Dunlap" Subject: Re: DSDT in initrd Date: Fri, 16 May 2003 16:04:46 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <20030516160446.287a16dd.rddunlap@osdl.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: "Grover, Andrew" Cc: mflt1-DTdK3Ks6N5kHTnRCetW4+N0b+6lKrnBL@public.gmane.org, len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org List-Id: linux-acpi@vger.kernel.org On Fri, 16 May 2003 15:50:40 -0700 "Grover, Andrew" 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