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 20:46:41 -0400 (EDT)

external call-out (was Re: apm proposed changes)

 > > 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 don't clearly understand how your method works (disclaimer: I also haven't
 > downloaded your snapshot).  Currently, in my version, we use the -s and -r
 > options to specify arbitrary commands to run on suspend and resume.  This
 > could be something like:
 > 
 >     apmd -s "cardctl suspend" -r "cardctl resume"
 > 		
 > or it could be what I do in the Debian package, which is:
 > 
 >     apmd -s "run-parts /etc/apm/suspend.d" -r "run-parts /etc/apm/resume.d"
 > 
 > From your description, it seems your version has a single dispatch command,
 > which (I guess) is called with some parameters specifying what just
 > happened.  It seems to me that you can duplicate this behaviour using the
 > implementation in my version:
 > 
 >     apmd -s "/sbin/apm-event suspend" -r "/sbin/apm-event resume"
 >     
 > Of course, it would be nice to have events for batteries, standby, and so
 > on, but that's pretty easy to add.  The advantage is that commands like
 > the first one above will work:  you don't _need_ a dedicated dispatch
 > command.  Further, the "event masking" is done simply by either supplying or
 > not supplying command-line options.

You are right about my technique.  I called the dispatcher
"/etc/apmd_proxy" and it is invoked with the APM BIOS event received,
as you indicate in your example.

Hmmm.  I can see both points of view.  On the one hand, it's nice to
be able to specify a certain command to run (your technique), because
it associates a definite action with an event.  On the other, I would
argue that having a central dispatcher has its benefits too:

 * Entire power management policy is kept in on single file.
   If it's a bash script, shared macros can be kept in the same
   file.
 * Since there is only one dispatch point, there are fewer chances
   for security problems.  I do some error-checking to make sure
   /etc/apmd_proxy exists, has the right permissions, etc.  Not
   clear how this can be done for an arbitrary command.  If /etc/apmd_proxy
   does not exist, then it isn't invoked.
 * The technique is similar to the technique of the PCMCIA package,
   which many users may be familiar with.
 * It easily scales with the number of APM events received.  There
   are about eight or nine APM events that can be delivered.  Not
   clear if you want to add that many command-line switches to apmd.
   [ You might say, "surely we don't want to add them all!" I might 
   respond, "why restrict a user's choices?" ]

Actually, I wouldn't be opposed to having *both* techniques.  :-)
Having event-specific command-line options for a few common events,
but use the dispatcher as a fall-back, might be a good combo.

 > And actually, I don't think it's a good idea to run commands when entering
 > or leaving standby (as opposed to suspend) modes.  If you run a program, the
 > drive will probably power up and the BIOS/kernel might leave standby mode
 > because there's system activity!  (This happens regularly on my laptop...)

First of all, the BIOS must allow disk (or other) activity during a
standby preparation, it's in the spec.  Period.  

Second, the sync() operation that "apm" and "apmd" both perform
guarantees that there will be disk activity before any kind of a
standby or suspend operation, so I don't see your side of the argument
there.  If it's really a problem, the user can put their proxy in a
RAMDISK, or not use one altogether.

Craig