Re: Attempted summary of suspend-blockers LKML thread

Paul E. McKenney
2010-08-02T01:11:48Z

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