APMD-List:
Archives

  From: Avery Pennarun <apenwarr@worldvisions.ca>
  To  : <apmd-list@worldvisions.ca>
  Date: Mon, 28 Sep 1998 21:56:40 -0400

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

On Mon, Sep 28, 1998 at 08:46:41PM -0400, Craig Markwardt wrote:

> 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.

Well, you can always use the "source" command or do what I suggested, eg.
"apm-event suspend" and "apm-event resume" -- you're still running the same
program.

>  * 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.

If no command is specified, it isn't invoked.  If one is, then invoke it. 
If the user tells you to do something stupid, do it anyway: maybe you just
don't understand why yet.  It's the Unix Way. :)

That said, my current 3.0beta code has some rather useless (and, I think,
nonfunctional) access checking on the supplied scripts.  I meant to take it
out, but haven't yet.

Of course, if you try to run a script and it doesn't work, print an error. 
That's just good manners.  As syslogd would say, "Last message repeated
253 times." :)

>  * The technique is similar to the technique of the PCMCIA package,
>    which many users may be familiar with.

Well, actually I find the pcmcia package to be needlessly confusing, but
maybe that's just me.

>  * 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?" ]

I was thinking about that.  We'd start running out of letters if we tried to
have one for each and every power management event.

> 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.

That wouldn't be too bad.  Keep -r and -s, maybe add an option or two for
leaving and entering battery mode, and add a mega '-D' (dispatcher) option
that receives all the events.  Oops... but then it's calling scripts every
time we enter/leave standby mode, which is pretty pointless since you almost
never want to do that.  I guess maybe (yikes) we could have bitflags, like
-D+sr-SR or something.

I'm starting to think that maybe we should just go with only your dispatcher
solution.  With Debian, at least, I was planning to just have a script that
runs everything in /etc/apm/apm-suspend.d or whatever anyway.  We could
change it to use /etc/apm.d, and have each script in there receive the APM
event options...

>  > 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.  

Sure, but it's not nice to see my hard disk spin up only to load the apm
event script (and subsequently, update its access time) only to spin down
again because we're going into suspend or standby, even if we improve apmd
to spin down the drive _immediately_ instead of after another timeout.

The tricky thing about power saving is trying to save as much power as
possible while doing as little as possible :)

> Second, the sync() operation that "apm" and "apmd" both perform
> guarantees that there will be disk activity [...]

Not really.  If there was nothing in the cache, nothing gets flushed.  You
notice disk activity whenever you run the sync _shell_ command because it
has to save the last-accessed time of the sync command and probably all the
libraries.

Have fun,

Avery