Date: Sun, 19 Sep 2004 14:55:49 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: trouble overriding DSDT Message-ID: <20040919215548.GA37391@dhcp44.pn.xcllnt.net> In-Reply-To: <414DF52E.1030109@root.org> References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <414CA156.7040606@root.org> <20040919163706.GA904@trimind.de> <414DF52E.1030109@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040919215548.GA37391>