trouble overriding DSDT
Nate Lawson
nate at root.org
Sun Sep 19 23:19:56 PDT 2004
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
More information about the freebsd-acpi
mailing list