Nigel Cunningham wrote: ...
Two way communication between a userspace policy manager and kernel drivers is implemented via DBus.
In this scheme, 'kernel drivers' doesn't just refer to the drivers for hardware. It refers to anything remotely power management related, including code to implement suspend-to-RAM, to disk or the like, ACPI drivers or code to implement system power states.
The policy manager can enumerate devices and inter-relationships, capabilities, settings and status information, set and query policies and implementation results. The drivers can notify events. This communication doesn't use complicated structures or type definitions. Rather, all the nous regarding interpretation of the messages that are sent is in the policy manager and the drivers. One driver might say it's capable of states called "D0, D1 and D3", another (system) states called "Deep Sleep" and "Big Sleep". Nothing but the driver itself and userspace manager need to how to interpret & use these states.
Inter-relationships between drivers are _not_ included in this information. The policy manager sets policy, the drivers deal with the specifics of implementing it.
This all sounds exactly like the way we're headed as well, so I'm definitely interested in anything I can do to help. Was thinking that can start defining kobject_uevent power events and attributes (with enough detail that acpid could use it instead of /proc if the ACPI drivers were to convert to it).
Capturing the relationships between drivers is difficult. If nobody's already looking into this then I'll take this up soon.
The userspace manager can in turn [en|dis]able capabilites and send a list of run-time states that the driver can move between according to its own logic (eg lack of active children) without notifying the userspace manager. This would fit in with your power modes above, even to the level of "cpu idle".
At dynamicpower.sf.net we do something similar for cpufreq-style scaling of platform clocks and voltages, setting up desired policy for various platform clocks/voltages according to changes in low-level system state (primarily scheduler state) from userspace and then letting the state machine run without interaction. Similar policy objects for devices sounds intriguing, although the device-specific nature of event triggers probably makes this quite difficult.
Mac OS X support for some of these concepts is documented at developer.apple.com, looking for ideas to steal... Thanks,
-- Todd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
