[lkml]   [2010]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take two
    On Thu, Aug 05, 2010 at 06:37:15AM -0700, Brian Swetland wrote:
    > On Thu, Aug 5, 2010 at 6:18 AM, <> 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
    > lazy.
    > 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).

    Thank you for the added detail on Android user-space operation!!!

    Thanx, Paul

    > Brian
    > > Quote:
    > >
    > >> 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.
    > >
    > > Brian
    > >
    > >
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-06 01:37    [W:0.132 / U:6.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site