APMD-List:
Archives

  From: David Brownell <david-b@pacbell.net>
  To  : <craigm@milkyway.gsfc.nasa.gov>
  Date: Thu, 17 Jun 1999 16:25:39 -0700

Re: apmd 3.0beta8 is released

Craig Markwardt wrote:
> 
> [ copied to the apmd-list ]
> 
>  > >      My only issue is with the actual power management policy
>  > > you have implemented.  My feeling was that we shouldn't implement
>  > > *any* policy (except for resetting the clock),
>  >
>  > I'd be interested in removing that clock stuff completely; most of
>  > the time, the kernel will handle it.  ...
> 
> I agree totally here.  I'm not sure myself why the clock setting logic
> was in apmd to begin with.  Probably because the kernel code used to
> lack it.  Can we just comment it out?

A quick glance at the kernel BIOS driver suggests it'd merit an
update first:  it should figure out any time zone delta nearer to
system initialization time, so that any APM_UPDATE_TIME events
delivered before the first suspend will be dealt with correctly.


Re having a "proxy" file that's not a NOP:

>  > Where I'm coming from:  95% of the users won't touch this file,
>  > so we should ship a policy that's sensible for them.  Whatever
>  > policy we provide can be overridden by a sysadmin or someone who
>  > provides a distribution ... but if we provide none, then folk
>  > are _needlessly forced_ to dive into system internals, and have
>  > no decent model to work from either.
> 
> Okay, I agree they should have a decent model.  Could it be *there*
> but commented out? 

Anything's possible!  But I'm not convinced there would be any
problems associated with a sensible default policy; certainly,
I think there will be fewer problems overall with one that pays
attention to power management than one that ignores it.  (Unless
the power management is notably buggy, in which case it'd be a
fine way to flush and fix the bugs!  ;-)

That is, why comment it out?  Most users don't edit /etc/ files and
frankly they shouldn't need to.


>	 What if "cardmgr suspend" causes excessive disk
> access, which causes the BIOS to reconsider the suspend event?  I
> think these issues crop up once in awhile.  I was hoping we could put
> the apmd_proxy on a ramdisk to avoid disk accesses.

My reading of the APM BIOS spec says that the BIOS concludes it'd
be a good time to suspend (or standby), and starts the operation.
Application level code that the BIOS driver talks to is expected to
do I/O, before it tells the driver to finish the suspend/standby
(or reject it).

That is, I don't think that the BIOS is even allowed to "reconsider"
in that way ... at least per the spec.  Now, folk who've spent time
talking to various BIOS implementations may be able to tell whether
this aspect of the spec is observed.  (I notice the APM driver doesn't
have a way to tell if the BIOS is "good" or "bad"; that could mean that
there are no problems like that, or that currently they're ignored.)


> I still argue that the power management policy is a *totally* personal
> thing.  I.e., you can't get 95% of the people to agree on what is
> reasonable.  Better to do nothing (which is backwards-compatible), but
> definitely provide guidelines.

I'd suspect that the power management policy shipped with MS-Windows
counts as reasonable.  Certainly it's what most of the world expects
as a default (IMHO reasonably):  when you're on battery power, lots of
power saving techniques kick in.  Details get tweaked, but by default
the policy is to conserve battery power.

- Dave