Date: Sun, 19 Sep 2004 23:19:53 -0700 From: Nate Lawson <nate@root.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-acpi@freebsd.org Subject: Re: trouble overriding DSDT Message-ID: <414E7689.80703@root.org> In-Reply-To: <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> <20040919215548.GA37391@dhcp44.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414E7689.80703>