From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 20 06:19:56 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8390016A4CE for ; Mon, 20 Sep 2004 06:19:56 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28D5743D41 for ; Mon, 20 Sep 2004 06:19:56 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.52] (adsl-64-171-186-250.dsl.snfc21.pacbell.net [64.171.186.250])i8K6Jown027868; Mon, 20 Sep 2004 02:19:51 -0400 Message-ID: <414E7689.80703@root.org> Date: Sun, 19 Sep 2004 23:19:53 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <414CA156.7040606@root.org> <20040919163706.GA904@trimind.de> <414DF52E.1030109@root.org> <20040919215548.GA37391@dhcp44.pn.xcllnt.net> In-Reply-To: <20040919215548.GA37391@dhcp44.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sascha Klauder cc: "Moore, Robert" cc: freebsd-acpi@freebsd.org Subject: Re: trouble overriding DSDT X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 06:19:56 -0000 Marcel Moolenaar wrote: > On Sun, Sep 19, 2004 at 02:07:58PM -0700, Nate Lawson wrote: > >>The right fix I think is to disable SSDT loading if we've overridden the >>DSDT. Bob, what do you think? Marcel, we should fix this for 5.3R >>because it will prevent people from using custom ASL easily. Another >>quick fix would be to put a comment block around the disassembled SSDT >>so it is there for inspection but doesn't affect recompilation. > > > Tricky. The advantage of SSDTs is that it allows you to modularize, > which means that one may want to be able to override a single SSDT. > In that case, overriding the DSDT does not automaticly imply that > none of the SSDTs should be loaded. > > If by default we do load SSDTs when overriding the DSDT (like we happen > to do now by coincidence), we should not dump any SSDTs by default in > acpidump(8) and vice versa. This also means that we should be able to > just dump some SSDT and override just some SSDT. > > If overriding is acceptable to be an all or nothing approach, then > acpidump(8) behaves correctly and we just need to stop loading SSDTs > when the DSDT is overridden. Overriding is only for debugging or for known-bad machines. So I think it's acceptable for the user to pass a combined/hacked DSDT+SSDT and have it override all DSDT/SSDT tables. This is the way I'd like to handle this. For now, I think it makes sense to put the SSDT in a comment block in acpidump(8) so that recompiling and overriding works properly and the SSDT is still available for examining. We can do the first fix in -current but we need something for 5.3. Objections? > I prefer the flexibility and given that we currently do load SSDTs, it > makes sense to at least enhance acpidump(8) to make dumping the SSDTs > optional when dumping the DSDT. Irrespective of what we'll do in the > future. This would be a good compromise to put in 5.3R... I'd like to still dump it but comment it out. This gives the info in the SSDT but points out that it's read-only. -Nate