Re: Attempted summary of suspend-blockers LKML thread, take two
From: Brian Swetland
Date: Thu Aug 05 2010 - 09:41:48 EST
On Thu, Aug 5, 2010 at 6:18 AM, <david@xxxxxxx> wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>> Continuing to rush in where angels fear to tread...
> here here :-)
>> o Â Â Â "PM-driving application" are applications that are permitted
>> Â Â Â Âto acquire suspend blockers on Android. ÂVerion 8 of the
>> Â Â Â Âsuspend-blocker patch seems to use group permissions to determine
>> Â Â Â Âwhich applications are classified as power aware. ÂMore generally,
>> Â Â Â ÂPM-driving applications seem to be those that have permission
>> Â Â Â Âto exert some control over the system's sleep state.
>> Â Â Â ÂNote that an application might be power-oblivious on one Android
>> Â Â Â Âdevice and PM-driving on another, depending on whether the user
>> Â Â Â Âallows that application to acquire suspend blockers. ÂThe
>> Â Â Â Âclassification might even change over time. ÂFor example, a
>> Â Â Â Âuser might give an application PM-driving status initially,
>> Â Â Â Âbut change his or her mind after some experience with that
>> Â Â Â Âapplication.
> One thing that I think it's important to document here is theinformation
> that Brian provided in response to your question about how many (or actually
> how few) applications fall into this catefory
I think I need to clarify here. When I say "app" in the context of
Android, I mean "an application running under the Android app model --
sandboxed under a per-app or app-group uid", not "a process". The
vast majority of processes on an Android device are "apps" in this
sense, but some (usually low level services or daemons) are not. Also
I use "wakelock" as a place holder for "suspend blocker" or whatever
exact API we're trying to hash out here, because it's shorter and I'm
Any app may obtain a wakelock through the standard Android APIs,
provided it has permission to do so. In the current implementation,
apps obtain wakelocks via making a binder RPC call to the power
manager service which tracks high level wakelocks (for apps!) and
backs them by a single kernel wakelock. Access control is at the RPC
level. This implementation could be changed to have the app API
simply open /dev/suspendblock or whatnot, with access control enforced
by unix permissions (the framework would arrange for apps with the
android "can block sleep" permission to be in a unix group that has
access to the device).
For native services (native daemons that run "underneath" the android
app framework -- for example the media service, the radio interface,
etc), the kernel interface is used directly (ok, usually via a very
thin C convenience wrapper).
>> I should have asked this earlier... ÂWhat exactly are the apps'
>> compatibility constraints? ÂSource-level APIs? ÂByte-code class-library
>> invocations? ÂC/C++ dynamic linking? ÂC/C++ static linking (in other
>> words, syscall)?
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. ÂChanging the basic kernel<->userspace interface (within
> reason) is not unthinkable. ÂFor example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use. ÂWe'd have to make some userspace changes to
> support that but they're pretty low level and minor.
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue). ÂA model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view. ÂWe
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/