David Brownell wrote: > On Friday 15 April 2005 7:53 pm, Todd Poynor wrote: >... >>On the other hand, I've been trying to push them toward a simpler-kernel >>model in which all the product-specific logic for placing various >>devices in designated power states occurs in a userspace power policy >>manager, > > So maybe you have some answers for me about why there should need > to be *any* notion of exporting device power states. (Rather than > not caring, and just requiring driver-internal powers states always > to become consistent with the upcoming system power state.) > > If one takes the notion of userspace managing those states off the table, > is there any other motivation to expose those device power states? So far as I have been able to determine, the usage you describe, as well as straightforward individual device power state management (power this device off upon receipt of some event, period of inactivity, etc.) is common, although with enough flexibility in creating custom system power states and reacting to those states in driver power controller objects, the second usage may be covered by the first. I believe in some cases power policy management applications are also examining device power state to make policy decisions, but I certainly recommend use of kernel-to-userspace notification of power events over such polling. If I recall any other more exotic things I've run across I'll post a response later. > I'm pretty sure that supporting this sort of userspace functionality > won't really fit into the "simpler kernel" rubric. If for no other > reason than the self-evident fact that a kernel exporting such stuff > must have more code than one not exporting it... It may not be simpler overall on the kernel side (at least prior to being customized for a particular policy, for which the in-kernel alternative does add some amount of code). It does, however, place the code implementing custom system power states and associated decisions on device power states (which might fall under the general category of "policy") in userspace and exports just enough kernel interfaces for controlling system and device power behavior to let userspace handle it. As I say, though, the userspace vs. kernel home for this isn't a matter of strong preference to me, but have suggested userspace device state management as arguably more in keeping with prevailing winds of kernel development. I don't mean to get hung up in the terminology, but I wouldn't call relatively infrequent changes to fairly large-grained device power states "micro-policy management" either -- there is plenty of room for more frequent, possibly finer grained, changes to device power characteristics in driver code based on device state or hardware capabilities (auto clock gating, power up/down according to app use...), the aggressiveness of which may also be a policy consideration to be configured, perhaps from userspace (at least MacOS seems to have such interfaces). -- Todd
