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@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
