[...]
> > ACPI != PM. I don't see why ACPI details should be exposed to PM
> > interface at all.
>
> ACPI has by far the richest set of capabilities. It is a superset of
> APM. Therefore a combined APM/ACPI interface is going to look a lot
> like an ACPI interface.
First, lets stop being so Intel/x86 centric ;-)
There are more PM interfaces than APM/ACPI as Stephen Rothwell pointed
out to me: more are already supported by the kernel. PPC has one, ARM
has one, etc. And that's not even touching on UPSs and miscellaneous
portable whatnots with their own special PM bits and pieces like IBM
laptops.
ACPI might be able to handle all that but it would require a very
complex interface, if what I've seen of ACPI is anything to go by. Is
this correct?
A much simpler interface might not lose much functionality.
> IMHO an abstracted interface at this point is overengineering. Maybe
> later it will make sense, though.
Each PM scheme has its own daemon and suspend/sleep tools at the
moment. It makes sense to have just one daemon and toolset so that
advanced functionality can be shared. Should the kernel present a
common interface like HID, or should the daemon be able to understand
all the various protocols (like gpm for mice)?
--http://www.penguinpowered.com/~vii - 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/