This week's episode of "Desperate Androids"

Posted Jun 10, 2010 11:05 UTC (Thu) by rvfh (guest, #31018)
Parent article: This week's episode of "Desperate Androids"

> add stub versions of the suspend blocker API

Weird that one would choose to use the API and not the code... I would think that one wants to get right is the API, the code that's below can then be changed to anything one wants it to be (QoS, wavelock, etc..)

This week's episode of "Desperate Androids"

Posted Jun 10, 2010 12:35 UTC (Thu) by nix (subscriber, #2304) [Link]

The code's invasive, implements a new userspace ABI that the kernel folks aren't sure they want, and implements semantics that aren't actually useful on hardware that can't suspend as fast as Android (i.e. nearly everything).

At least with stubs the Android *drivers* can go in without pervasive changes.

This week's episode of "Desperate Androids"

Posted Jun 10, 2010 17:53 UTC (Thu) by iabervon (subscriber, #722) [Link]

The API for a driver to say "I've started something that needs to finish before the system can be considered idle enough to suspend" and "This thing is done now" should be pretty obvious. Even if some sort of QoS thing turns to be the real API, the above is still going to be a common enough case to justify having a helper rather than making everybody open-code the necessary QoS-setting call.

Of course, if the kernel lacks a mode where the system suspends because it is idle, the implementation is uncontentious: the kernel doesn't need to do anything when drivers call those functions. So Android drivers would be able to act to keep the kernel from autosuspending at a bad time, because a mainline kernel doesn't autosuspend ever and a kernel with autosuspension does something real with those functions.