| |||||||||||||
An alternative to suspend blockersAn alternative to suspend blockersPosted Nov 24, 2010 22:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)Parent article: An alternative to suspend blockers
>Then, if the /sys/power/wakeup_count interface is used correctly, the resulting kernel will be able to abort suspend in progress in reaction to wakeup events in the same circumstances in which the original Android kernel would do that. Yet, user space cannot access wakeup source objects, so the part of the wakelocks framework allowing user space to manipulate them has to be replaced with a different mechanics implemented entirely in user space, involving a power manager process and a suitable IPC interface for the processes that would use wakelocks on Android.
Why can't we just create a '/dev/wakelock' device, which calls wakeup_source_create() when it is opened? And add a few ioctl()s to allow userspace to set descriptive names for wakelocks.
Additional userspace IPC framework looks almost exactly like the kernel API.
Or am I missing something?
(Log in to post comments)
An alternative to suspend blockers Posted Nov 25, 2010 22:57 UTC (Thu) by rvfh (subscriber, #31018) [Link]
My thought exactly. This should also take care of processes crashing (and thus having their fds closed).
One could: * open device on app start if privileges satisfied (so not all apps can) * ioctl to lock/unlock * close automatically unlocks
Maybe the wakelock name should just be the app name and PID?
Or are we missing something?
An alternative to suspend blockers Posted Nov 28, 2010 0:06 UTC (Sun) by rjw@sisk.pl (subscriber, #39252) [Link]
Kernel developers are generally opposed to adding a separate /dev interface specifically for this purpose, generally speaking because it will only be useful to Android at this point (no one else seems to be interested in it, because user space on the other systems would have to be modified to use this interface).
An alternative to suspend blockers Posted Nov 28, 2010 20:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
So? It'll still be _cleaner_ than a userspace IPC daemon which essentially does the same thing.
And not accepting a driver for being Android-specific - that's also strange. Anyway, when suspend blockers infrastructure is in place, all it takes to provide /dev/wakelocks is a small loadable module which can live out-of-tree.
|
|||||||||||||