APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : <apmd-list@worldvisions.ca>
  Date: Fri, 18 Jun 1999 15:03:32 -0400 (EDT)

Re: apm daemon, suspend/resume

[ Discussion with PCMCIA maintainer David Hinds forwarded with permission. ]

David Hinds writes:
 > On Thu, Jun 17, 1999 at 07:47:02PM -0400, Craig Markwardt wrote:
 > > 
 > > There have been some recent improvements to apmd, the user-land daemon
 > > that does APM logging.  apmd is now much more flexible about
 > > performing user-specified actions before and after APM events ( see
 > > http://www.worldvisions.ca/~apenwarr/apmd/ ).  A small dispatcher
 > > script called /etc/apmd_proxy is called for most APM events.
 > > 
 > > The question we have been discussing now is, what default policy, if
 > > any, should be applied.  For example, the script currently calls
 > > "cardmgr suspend" and "cardmgr resume" for suspend and resume events.
 > 
 > You mean "cardctl suspend" and "cardctl resume", right?
 > 
 > > I am also aware that the PCMCIA kernel modules directly receive APM
 > > events and respond to them.  However, cards are hard suspended,
 > > right(?)
 > 
 > What do you mean by "hard suspended"?
 > 
 > When a PCMCIA client gets a suspend signal, it is supposed to cease IO
 > to the card, and the core modules then power down the socket.  When a
 > resume is received, the socket is powered up and the client performs a
 > full reset of the device.
 > 
 > > So, are there any peculiar interactions we should be worried about
 > > during a suspend or resume?  Is calling "cardmgr suspend" okay if the
 > > kernel services have just been suspend or are about to be?
 > 
 > For PCMCIA, the cardmgr daemon actually receives the suspend event and
 > does the equivalent of a "cardctl suspend".  So I'm surprised that it
 > makes any difference if you have apmd do the same thing: are you sure
 > that this has any effect?
 > 
 > -- Dave
 >