APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : Avery Pennarun <apenwarr@worldvisions.ca>
        <apmd-list@worldvisions.ca>
  Date: Mon, 28 Sep 1998 21:01:02 -0400 (EDT)

Power management policy

I keep talking about the small stuff, but maybe I should outline a
little more of my idea of what "apmd" *should* be.

Right now, apmd does the following things:
 * critical event logging
 * some suspend preparation and resume recovery
 * battery logging

I think we both agree that each person's machine is different, and
they have different expectations for what it should do.  In fact, and
this is especially true for mobile computers like laptops, people
probably expect different things from their computer, depending on
where it is.

Regarding power managment, probably most people want their machine to
do different things depending on the circumstances.  The most obvious
thing is making the decisions based on whether AC power is connected.
For example, if AC power is connected, most people want a
"performance" machine, with infrequent screenblanks or disk spindowns,
etc.  If running on battery power, people want a "conserving" machine
which blanks the screen often, enters standby quickly, etc.

All of these decisions might be collected into one coherent plan, call
it a power management *policy*.  Look on a windows machine, and many
new ones have a pretty good set of choices regarding the policy.

Every laptop, and every laptop user, is different.  Ergo, each policy
can be different.  I believe we should be as accomodating as is
reasonable to allow users to achieve their own power management
policy.

Now, I know that apmd probably should not be changed radically to do
this.  On the other hand, a few things can be done to make it more
policy-friendly.  Specifically:

 * allow rejection of standby events upon user-determined criteria.
 * call a user-specified function when (almost) event occurs that
   could effect the policy.

These are straightforward to implement (I have done it already), and
put the user in the driver's seat.  Of course, a lot of users won't
want to be in the driver's seat, but then they should have a default
power management policy which applies to the common denominator
(e.g. *no* power management).

Craig

P.S.  I could envision a more active power management daemon.  One
that coordinates activities optimally.  [For example, managing the
hard disk standby, and calling bdflush() immediately before a hard
disk spindown].  That's probably best left to another separate
program.  apmdplus? :-)