APMD-List:
Archives

  From: Peter Englmaier <ppe@pa.uky.edu>
  To  : Avery Pennarun <apenwarr@worldvisions.ca>
  Date: Mon, 2 Aug 1999 17:10:26 -0400 (EDT)

Re: New apmsleep utility

Avery wrote:
> I'm not saying to do it in the ugliest possible way :)  The reason I suggest
> it is that cron and at are the time-based-event schedulers in Unix; if my
> laptop is suspended, my cron jobs won't run when (presumably) I expect them
> to.  It would be relatively trivial (famous last words) to have cron run
> "apmsleep --noapm" to wake up for its next job, before it next goes to
> sleep.

Well, it doesn't sound completely wrong to me, but you know there are
already two 'laptop' versions for cron around and cron is a larger piece
of code. Also, I do *not* want my laptop to wakeup only to rotate 
logfiles. If we choose crond, than I would propose to make a special
version of it [apm_crond?] and make a backwards compatible crontab
format extension, e.g:

# announce time every quarter, but not while sleeping
0,15,30,45 8-12 * * * saytime           >/dev/null 2>&1
# do it always if we have something to do:
-always -onlyif ~/fax_avail 0 3 * * * send_faxes
# wake up every hour and say time
-sleep 0 0-7,13-23 * * * saytime
# wake up in the morning
-on 0 8 * * * true		(dummy job 'true')
# shutdown when idle
-off 0 23 * * * true

Still you need a config file, of course.  But it should be an
extension/separate program, because not everybody wants it.

> The problem you mention about only allowing for one pending event on the
> entire system does make things worse... perhaps the kernel driver needs to
> be modified to improve that situation.  It would be nice if the kernel just
> scheduled an alarm for the "earliest" requested event, then queued the next
> one afterwards.

The pending 'alarm' interrupt/ hanging around apmsleep is not
necessary, as long as you can ask crond or at to schedule an
'apmsleep' when its fine to do so immediately. 

> I really would like to transfer control of the APM functions away from the
> BIOS and into Linux -- that way, we could dodge bugs caused by "impatient"
> bioses (that really, really want to suspend within a second or two after
> generating a suspend event).  Plus, we would have an obvious way to control
> which devices do/don't affect automatic standby and suspend.  
Oh, ok, that's your real concern...  For urgend 'suspend' events (like
battery low), there could be a queue of sleeping emergency programs
for each critical device (with memory blocked from swapping out). The
kernel would just manage the queue, and the emergency programs could
be kernel modules (when loaded, they register for the queue, when
unloaded, they unregister), or just part of the driver.

> I'm especially interested in having a way to hold off suspending
> until the load average goes down.
But than you can't do it in a few seconds. There is a special file
/proc/loadavg you could use. Just add this feature as an option to
apm.

> But as usual, I don't have time to implement this myself.
It's always good to have some ideas waiting.

Cheers,
Peter.