> > battery status, the steps the OS must perform are defined by the BIOS.
> > However, since they are performed by the OS, the OS in fact gains visibility
> > into the process, and does not ever relinquish control to the BIOS.
>
> It has task file IDE access. It is capable of being abused for that or more.
> Intent doesnt come into it. Its no different to the current BIOS SMM
> situation.
That's not his point. ACPI is doing what the BIOS tells us, not asking the
BIOS to do something for is. That's not a Good Thing, but it's Better.
Unless you're proactive about scanning BIOS routines for power mgmt,
verifying tables, and analyzing AML before you use it, you won't know
something is wacky until it bites you.
With AML, at least you have the freedom to pinpoint the problem and
overridde it, either by modifying the table yourself, or providing a new
one(*).
I'm a big ACPI pundit, and disagree with many aspects of the spec and
implementation. But, a) we're stuck with it and b) it's a lot better in
many aspects than previous things, including the ability to catch and work
around problems rather than just punting on them.
-pat
(*) Aside from any potential copyright infringement on the tables
themselves. But, it is theoretically possible to override the DSDT with
one provided at runtime. So, if someone finds a problem with Company X,
Model Y's AML, they can go to acpi.sf.net and download a fixed table, run
a utility to put it in the early init scripts, reboot and be safe.
Hypothetically.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/