Date: Mon, 20 Sep 2004 11:59:33 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: "Moore, Robert" <robert.moore@intel.com> Subject: Re: trouble overriding DSDT Message-ID: <200409201159.33995.jhb@FreeBSD.org> In-Reply-To: <414E7689.80703@root.org> References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <20040919215548.GA37391@dhcp44.pn.xcllnt.net> <414E7689.80703@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 20 September 2004 02:19 am, Nate Lawson wrote: > 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 think it's a good idea to override all the DSDT+SSDT's when you load a new dsdt. Otherwise it just makes things much more complicated for the user to have to know what lives in different SSDT's, etc. If acpidump continues to dump a full table that can then be compiled into a single foo.dsdt that makes the user interface a lot simpler and easier to manage. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409201159.33995.jhb>