APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : <apmd-list@worldvisions.ca>
  Date: Sun, 27 Sep 1998 12:45:59 -0400 (EDT)

apm proposed changes

To recap: I have submitted some proposed changes to Stephen Rothwell
(the Linux kernel APM maintainer).  I haven't heard back from him yet,
and would kind of like to wait to hear his comments. The main essence
of the changes are:

  * implement (almost) full APM 1.2 BIOS spec, with exposure an via
    ioctl interface.

  * more detailed report in /proc/apm, while still maintaining
    compatibility with old versions. 

  * ability for user-level code to *reject* a pending standby or
    suspend event.  Very handy if something nasty is going on.


I had been working on my own copy of the user-level APM utilities,
including both apmd and apm (based on Faith's 2.4 version).  It seems
we may have diverged here.  Hmmm.

Regarding APMD
--------------

I like the approach of being able to call a function when there is a
pending event, and I see you have enabled an external callout
mechanism for some APM events.  I attempted to make a more general
approach, using a single "proxy" command which acts as a dispatch
point for *all* apm events (well, the events are maskable).  I
personally kind of like this idea, because it allows users to devise
their own power policy.  [The user can prepare their system for
standby/suspend by shutting down PCMCIA services, and then restore
them upon resume; or take a special action when AC power changes. ]

Unfortunately, in my hacking on apmd, I have made other serious
changes.  Mostly, this was in clarifying the logic, but I fear that
the divergence with your code is severe.  On the plus side, I have
been running my code stably for several months :-)

You can see a snapshot in:

ftp://lheaftp.gsfc.nasa.gov/pub/craigm/apm

apmd-cm.tar.gz    - snapshot of my APMD development track (look for "proxy")
kernel-apm.tar.gz - what I submitted to Stephen.

More work needs to be done to make the user-level routines compatible
with older kernels.

Regarding APM
-------------

Most of the changes I have made here are to enable new features in the
kernel.  Since the kernel issue is still in a state of flux, maybe
that should wait a bit.

Regarding APMLIB
----------------

There are a few things about the apmlib that I would like to discuss,
from a design perspective.  These are mostly small things, but I think
they would make the library more useful and perhaps "correct."

* First, I feel the "standby" and "suspend" routines are a little
  awkward, because they call sleep and sync.  In my opinion this is a
  mistake, because this is functionality that belongs in apmd.c alone,
  if that.
  
  For an example of how this is a problem, look at what happens when
  a user types "apm --standby"

  APM: calls sleep()
  APM: calls sync()
  APM: invokes standby IOCTL
  APM_BIOS: prepares to enter standby, sends standby event to APMD
  APMD: calls sleep()
  APMD: calls sync()
  APMD: invokes standby IOCTL
  APM BIOS: enters standby mode.

  It's this calling sleep and sync twice, through apmlib, that doesn't
  seem right.  I think these calls should go into apmd.c, and apmlib
  should only call the IOCTL.  In fact, I think the sleep and sync
  should go into the proxy function.  The user should be able to
  decide what to do [for example, if the machine stays alive but in a
  clock-slowed mode, then the delay/sync may not be needed].

* The sequence in apm to open the apm device seems a bit wasteful.
  The sequence is: apm_exists -> apm_open -> apm_read, and each one
  (I think) opens /proc/apm

  It has been my experience that APM bios calls (implicitly made when
  opening /proc/apm) can eat a fair amount of CPU with interrupts off.
  Would be nice to open /proc/apm only once and cache the results.

* The apm_read functionality could be more flexible.  Currently only
  the APM bios device can be select()'ed.  It would be nice to be able
  to separate the select and the read, so that a program could keep
  track of other file descriptors.  For example, a more intelligent
  power manager daemon might need this.

Well, this email is already too long.  It would be nice to hear your
thoughts.

Craig