APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : David Brownell <david-b@pacbell.net>
  Date: Thu, 17 Jun 1999 17:25:18 -0400 (EDT)

Re: apmd 3.0beta8 is released

[ copied to the apmd-list ]

David Brownell writes:
 > 
 >  
 > > You've also changed the battery discharge rate to be based on the
 > > "minor" instead of "major" checkpoint.  One could argue both ways on
 > > this.  By using the most recent minor checkpoint, we only get a
 > > discharge of a few percent over a few minutes.  That might not get an
 > > precise enough read of the true discharge rate.  The original apmd
 > > essentially calculated the rate based on the "major" check point
 > > (although it wasn't called that).
 > 
 > I'm not religious on that one, and don't recall right off why
 > I changed it.  It may even have been accidental.   Incremental
 > (dis)charge rates will vary more than the average one though,
 > hence be a bit more informative ... discharge rates averaged
 > over ten percent of battery life _should_ be reasonably precise.

Isn't it five percent?  Hmmm, maybe that's my own personal setup.  I
think the original idea was to use the cumulative run-down to predict
future battery lifetime.  The battery discharge rate is used to
predict how much life is left.  Therefore it's possible that a person
could use their machine lightly for a short time and apmd predicts a
large or even infinite lifetime.  Especially true if the "-c" option
is used.

 > >	  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.  Since it's not the sort of
 > thing I like to see in userland, I'd prefer to have the kernel be
 > handling it consistently.  I left it in (though I updated it a bit
 > so the "-u" stuff got picked up automatically on Red Hat) since I
 > wasn't sure it was safe to remove it yet.
 > 
 > Stephen -- any comments on that one?

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?

 > >	 and leave that up to
 > > the individual sysadmin.  We can't know what power management policy
 > > people will want ahead of time.  For example, somebody on a desktop
 > > machine will probably not have the PCMCIA package installed, but may
 > > still want APM.  Or the policy of rejecting system standby/suspend
 > > events may not be what is wanted.
 > 
 > I'm coming at this a bit differently -- though you'll notice that
 > what I provided behaves fine in the case of a desktop without PCMCIA
 > support, so we're not that far off.
 > 
 > 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?  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.

 > > As to specifics.  You call "cardmgr suspend" explicitly.  In most
 > > cases this should not be necessary, since the PCMCIA kernel modules
 > > have a direct connection to the kernel APM module and gets messages
 > > that way.  I agree, some people need this, so I would argue that it
 > > should be left in the proxy file, but commented out.
 > 
 > The thing is that the kernel doesn't do anything except suspend the
 > card ... no interaction with other services.  The PCMCIA package does
 > the rest of that important stuff, AND in a way that's reasonably well
 > understood already.  Using it hits that "sensible for the 95% rest of
 > us" criteria.

Again, how about there but commented?

 > > Unfortunately Stephen Rothwell hasn't implemented rejection events in
 > > the official kernel APM module yet.  Thus, putting "exit 1" may
 > > actually be counterproductive.
 > 
 > That bit of policy was yours ... personally, I'd have voted to have
 > the default policy be "green" rather than "spend that AC power", but
 > since your original policy met my criteria ("sensible for the 95%")
 > I left it as is.

Argh, I meant to sneak that one out. :-) My kernel does just fine
thank you very much.

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 asked Stephen a similar thing, and half volunteered to help implement
 > that feature.  We'll see -- I've got some travel upcoming.

Yes, I have done it, and so has another intrepid person.  I can supply
my modifications (for 2.0.* and 2.1.* series kernels) if desired, but
the it seems like everybody has to take a number to get some Linus
mind share.

Craig