Re: [9fans] alarm handling and suspended machines

[F.J.Ballesteros <nemo@gsyc.escet.urjc.es>]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

In any case, I now think that it would be better to prevent alarm(2)
from resuming a suspended machine; otherwise the user would need to be
careful not to start any periodic-alarm program (listen, etc.).

By the way, I have just compiled a kernel that has /dev/resume and
allows a write to set up a wake up timer. My problem now is that the
bitsy is ignoring the RTC alarm I set. I'm trying to see what I did
wrong...


One thing I think we need is to unify the apm interface.  It would be
nice to have a single set of files in /dev supplying the interface to
suspend/resume/battery status.  Right now my stats has to try twice to
display the battery status, since it has to work both with /mnt/apm and
with /dev/battery.

Any plans on this?


[-- Attachment #2: Type: message/rfc822, Size: 1707 bytes --]

From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] alarm handling and suspended machines
Date: Tue, 12 Jun 2001 23:27:34 -0400
Message-ID: <20010613110506.64C19199E3@mail.cse.psu.edu>

we were about to do that on the pc's for a different reason.  The
mechanism should extend to the other architectures.  I've got to
figure out how to restart time when the fast clock stops running.
I can do a quick guess from the rtc and then use ntp to do the
rest but the timesync process will have to know when the
cycle clock becomes meaningless.