| |||||||||||||
An alternative to suspend blockersAn alternative to suspend blockersPosted Nov 25, 2010 22:57 UTC (Thu) by rvfh (subscriber, #31018)In reply to: An alternative to suspend blockers by Cyberax Parent article: An alternative to suspend blockers
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?
(Log in to post comments)
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.
|
|||||||||||||