From: John Stultz <john.stultz@linaro.org>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: linux-kernel@vger.kernel.org,
Brian Swetland <swetland@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Alessandro Zummo <a.zummo@towertech.it>,
rjw@sisk.pl
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers
Date: Thu, 06 Jan 2011 18:30:20 -0800 [thread overview]
Message-ID: <1294367420.4518.171.camel@work-vm> (raw)
In-Reply-To: <AANLkTin8cntsFpaikpfzPbWL1YFb702rPync240X4axW@mail.gmail.com>
On Thu, 2011-01-06 at 16:58 -0800, Arve Hjønnevåg wrote:
> 2011/1/6 John Stultz <john.stultz@linaro.org>:
> > So otherwise, do you see any reason why android might not be able to
> > adapt this code to replace the android alarm timers?
> >
>
> The user-space interface does not look appealing, but I don't see any
> reason why the in-kernel interface(s) cannot be shared. Our user-space
> code has a single thread that waits for alarms to trigger, while the
> alarms can be modified from any thread.
So its something like nanosleep(), only other threads can extend or
shorten the sleep time?
Could you explain some of the rational for such an interface, so I can
better understand the need?
> As far as I can tell, using
> the posix interface would either require a thread per alarm (up to 5)
> or using signals. Both make the user-space code more complicated, and
Yea, it probably would need signals, but I'd have to grok the use case a
little better. And its possible it would complicate the user-space code
some, but on the other hand, it would be using a more standard kernel
interface. The other option is extending the posix interface to try to
better match the need.
> it is not clear if either of them provide a clear hand-off between
> where the kernel needs to block suspend because the alarm has not been
> delivered to user-space and where user-space needs to block suspend
> because it is handling the alarm.
Indeed. I'm still looking into the pm_wake details to see the
limitations there. Some method of inheriting a stay_awake seems to be
needed, but sounds pretty ugly. Alternatively we may need some method or
callback to the kernel to detect that a signal has been handled by
userland (allowing the pm_relax to occur).
Rafael: Any thoughts here?
thanks
-john
next prev parent reply other threads:[~2011-01-07 2:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 2:15 [PATCH 00/12] Posix Alarm Timers full patchset John Stultz
2011-01-06 2:15 ` [PATCH 01/12] timers: Introduce timerlist infrastructure John Stultz
2011-01-06 2:15 ` [PATCH 02/12] timers: Rename timerlist infrastructure to timerqueue John Stultz
2011-01-06 2:15 ` [PATCH 03/12] timers: Fixup allmodconfig build issue John Stultz
2011-01-06 2:15 ` [PATCH 04/12] hrtimers: Convert hrtimers to use timerlist infrastructure John Stultz
2011-01-06 2:15 ` [PATCH 05/12] hrtimer: fix timerqueue conversion flub John Stultz
2011-01-06 2:15 ` [PATCH 06/12] RTC: Rework RTC code to use timerqueue for events John Stultz
2011-01-06 2:15 ` [PATCH 07/12] RTC: Remove UIE emulation John Stultz
2011-01-06 2:15 ` [PATCH 08/12] rtc: Namespace fixup John Stultz
2011-01-06 2:15 ` [PATCH 09/12] [RFC] hrtimers: extend hrtimer base code to handle more then 2 clockids John Stultz
2011-01-06 2:15 ` [PATCH 10/12] [RFC] hrtimers: Add CLOCK_BOOTTIME clockid, hrtimerbase and posix interface John Stultz
2011-01-06 2:15 ` [PATCH 11/12] timers: Add rb_init_node() to allow for stack allocated rb nodes John Stultz
2011-01-06 2:15 ` [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers John Stultz
2011-01-06 4:07 ` Arve Hjønnevåg
2011-01-06 18:04 ` John Stultz
2011-01-07 0:58 ` Arve Hjønnevåg
2011-01-07 2:30 ` John Stultz [this message]
2011-01-08 10:36 ` Rafael J. Wysocki
2011-01-13 5:03 ` Arve Hjønnevåg
2011-01-11 18:56 ` John Stultz
2011-01-11 19:22 ` Anca Emanuel
2011-01-13 4:50 ` Arve Hjønnevåg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1294367420.4518.171.camel@work-vm \
--to=john.stultz@linaro.org \
--cc=a.zummo@towertech.it \
--cc=arve@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=swetland@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox