lkml.org 
[lkml]   [2010]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] Attempted summary of suspend-blockers LKML thread
    On Sun, Aug 01, 2010 at 06:16:33PM -0500, James Bottomley wrote:
    > On Sat, 2010-07-31 at 22:48 -0700, Paul E. McKenney wrote:
    > > On Sat, Jul 31, 2010 at 09:52:14PM -0700, Arjan van de Ven wrote:
    > > > On Sat, 31 Jul 2010 10:58:42 -0700
    > > > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
    > > >
    > > > > o "Power-aware 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, power-aware applications seem to be those that
    > > > > have permission to exert some control over the system's
    > > > > power state.
    > > >
    > > > I don't like the term "Power aware application". An application is well
    > > > behaved or it isn't. "aware" has nothing to do with it.
    > >
    > > Applications are often complex enough to be aware of some things, naive
    > > about others, well behaved in some ways, and ill-behaved in others.
    > > This has been the case for some decades now, so it should not come as
    > > a surprise.
    > >
    > > I am of course open to suggestions for alternatives to the term "power
    > > aware application", but most definitely not to obfuscating the difference
    > > between power awareness (or whatever name one wishes to call it) and
    > > the overall quality of the application, whatever "quality" might mean
    > > in a given context.
    >
    > So the reason everyone's having trouble with this definition is that it
    > actually conflates two separate axes of power management.
    >
    > There are good and bad applications in the power sense ... burns less vs
    > burns more.
    >
    > And there are user mandated vs user optional processes ...
    > necessary/wanted vs unnecessary/unwanted.
    >
    > What android actually does is reward well written applications because
    > they "just work" and they don't have to be power aware at all ...
    > they're usually event driven and split into the android
    > provider/consumer model.
    >
    > Badly written applications that are not suspend block aware get shut
    > down (by system suspend) when the screen turns off, so they're also
    > power/suspend unaware.
    >
    > Applications that want to present the user with a choice in android are
    > power/suspend aware because the only way they get to present the choice
    > is via suspend blockers.
    >
    > The "power problem" always devolves to resolving a set of choices around
    > a given set of control axes. The problem is that the set of control
    > axes isn't unique and doesn't have a well agreed upon selection. This
    > makes it hard to make definitive terminology because you have to pick
    > the set of axes (implicitly or explicitly) before defining terms ...

    That does seem to be about the size of it... :-/

    Thanx, Paul


    \
     
     \ /
      Last update: 2010-08-02 03:15    [W:0.024 / U:0.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site