cvs commit: src/usr.sbin/acpi/acpidump acpi.c acpidump.c
jhb at FreeBSD.org
Tue Oct 5 11:08:46 PDT 2004
On Tuesday 05 October 2004 01:50 pm, Nate Lawson wrote:
> Takanori Watanabe wrote:
> > In message <200410050218.i952IrBK008982 at repoman.freebsd.org>, Nate Lawson
> > wrote
> >>njl 2004-10-05 02:18:53 UTC
> >> FreeBSD src repository
> >> Modified files:
> >> usr.sbin/acpi/acpidump acpi.c acpidump.c acpidump.h
> >> Log:
> >> Add the -s flag to make dumping SSDTs optional (disabled by default).
> >> Since we can only override the DSDT, a custom ASL dumped previously that
> >> contained SSDTs would result in lots of multiple definition errors.
> >> A longer-term fix involves adding the ability to override SSDTs to
> >> ACPI-CA.
> > iasl(8) may have to be able to compile multiple AML codes from single
> > ASL data, instead of merging SSDT into DSDT in acpidump(8).
> I think the most straightforward fix is for ACPI-CA to not load SSDT
> tables when the user is overriding the DSDT. If you treat overridden
> SSDTs separately, you go down the path of having to specify _which_
> table you want to override, which implies you need strict ordering of
> tables in both ASL and AML and it just gets too complicated. Some HP
> Itanium machines have 8 to 10 SSDTs.
I agree. It makes the user's lives a lot easier if they procedure remains:
- acpidump > foo.asl
- hack on foo.asl to fix it
- compile foo.asl to foo.dsdt
- load foo.dsdt in the loader
and have it all just work. Actually, you know, we could make this work on our
own without requiring ACPI-CA to change. You just need to hack
AcpiOsTableOverride() in OsdTable.c to return a pointer to an empty table for
"SSDT" tables when the DSDT is overridden. In fact, I think that is probably
where this behavior decision really belongs.
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the cvs-src