| |||||||||||||
Waking systems from suspendWaking systems from suspendPosted Mar 5, 2011 7:48 UTC (Sat) by swetland (subscriber, #63414)In reply to: Waking systems from suspend by PaulMcKenney Parent article: Waking systems from suspend
We (the Android Kernel Team) expect that we will be able to move to the driver level API side of the wakelock/suspendblock work to shift our driver work to be mainline-friendly.
The last proposals I've seen around userspace interface and suspend interface involve polling/spinning and I doubt we'll make use of them. The nice thing is this is pretty localized so it'll be easy enough to maintain patches for a reasonable userland interface on our side and not have to worry about any special changes for drivers. A nice step forward.
Regarding timer interfaces, are there non-signals-based ways of interacting with posix timers? Being able to select() on an fd for an alarm event works very well for us now and we're not terribly keen on moving to a signals-based universe.
(Log in to post comments)
Waking systems from suspend Posted Mar 5, 2011 23:34 UTC (Sat) by jstultz (subscriber, #212) [Link]
clock_nanosleep() might be one possibility?
Although from my brief discussions with Arve it sounded like the semantics of the android alarm timer interface is a little particular (especially with regards to wakelocks), so I doubt there will be an alternate implementation that will provide an exact 1:1 mapping.
That said, the rework of the RTC layer as well as the implementation of CLOCK_BOOTTIME (tglx just pulled it into -tip) will hopefully greatly simplify the android alarm timer code. So there may be a future for both the posix alarm timers and some form of the /dev/alarm device to co-exist, sharing a good bit of code.
Even so, while I think the posix interface for alarm timers provides a fairly nice and consistent interface that application developers are used to using, I'd greatly appreciate feedback and suggestions for alternative interfaces. Maybe we need something like clock_select()?
Waking systems from suspend Posted Mar 7, 2011 14:39 UTC (Mon) by alonz (subscriber, #815) [Link] Wouldn't it be better to just enhance timerfd() so it can take these new types of clock IDs as well as CLOCK_REALTIME / CLOCK_MONOTONIC?
Waking systems from suspend Posted Mar 7, 2011 18:16 UTC (Mon) by jstultz (subscriber, #212) [Link]
That might be a good approach. I'll look into it!
|
|||||||||||||