From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 19 21:55:51 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 5FD2016A4CE for ; Sun, 19 Sep 2004 21:55:51 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1F843D31 for ; Sun, 19 Sep 2004 21:55:50 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp44.pn.xcllnt.net (dhcp44.pn.xcllnt.net [192.168.4.244]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i8JLtoRD032153; Sun, 19 Sep 2004 14:55:50 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp44.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp44.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i8JLtoQd040492; Sun, 19 Sep 2004 14:55:50 -0700 (PDT) (envelope-from marcel@dhcp44.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp44.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i8JLtnkH040490; Sun, 19 Sep 2004 14:55:49 -0700 (PDT) (envelope-from marcel) Date: Sun, 19 Sep 2004 14:55:49 -0700 From: Marcel Moolenaar To: Nate Lawson Message-ID: <20040919215548.GA37391@dhcp44.pn.xcllnt.net> References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <414CA156.7040606@root.org> <20040919163706.GA904@trimind.de> <414DF52E.1030109@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414DF52E.1030109@root.org> User-Agent: Mutt/1.4.2.1i 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: Sun, 19 Sep 2004 21:55:51 -0000 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. 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... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net