Ah, understood. For whatever reason, I thought you were trying to re-implement John's patches as opposed to building a user-space API for them. Agreed, it would be quite hard to properly handle wakeup events in user space, given that the kernel needs to be involved in the wakeup/resume process!
Current best guess at Android suspend-blocker requirements
Posted Oct 2, 2011 23:43 UTC (Sun) by neilbrown (subscriber, #359)
[Link]
Yes and no.
Some of John's patches were just bug-fixes. The wakeup event from the CMOS timer wasn't being counted as a wakeup event properly. Those patches I wasn't trying to re-implement - they are good.
The other patches from John did things to the scheduler so that distinguished processes could prevent suspend just by being busy. I was trying to show that these patches were not necessary because a completely race-free protocol is available in userspace.
(and finally there was a patch which tried to make /sys/power/state resistant to processes that didn't follow the wakeup_count protocol. That issue is best addressed by fixing the processes, or bind-mounting a file over /sys/power/state).
Current best guess at Android suspend-blocker requirements
Posted Oct 3, 2011 16:18 UTC (Mon) by PaulMcKenney (subscriber, #9624)
[Link]
Cool! But I must defer to John and the Android guys at this point, as they would have a better idea of what works and does not in the Android environment.
My guess is that if they needed something lighter weight, this same general approach could be implemented within a device driver, though an implementation that just used existing user-space interfaces would be preferable, all else being equal. (Which it never is, but that is life!)