Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751774Ab0HAWQ7 (ORCPT ); Sun, 1 Aug 2010 18:16:59 -0400 Received: from netrider.rowland.org ([192.131.102.5]:38342 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751695Ab0HAWQ6 (ORCPT ); Sun, 1 Aug 2010 18:16:58 -0400 Date: Sun, 1 Aug 2010 18:16:57 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: "Paul E. McKenney" cc: linux-pm@lists.linux-foundation.org, , , , , , , , , , Subject: Re: Attempted summary of suspend-blockers LKML thread In-Reply-To: <20100801201117.GO2470@linux.vnet.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2349 Lines: 55 On Sun, 1 Aug 2010, Paul E. McKenney wrote: > > I should have made a stronger point: "power-aware" is _not_ a good > > term for these applications. "power-enabled" would be better but > > still not ideal. Maybe "power-permitted"? The definition is that > > they are _permitted_ to do something (acquire suspend blockers), not > > that they actually _do_ something. > > How about "PM-driving applications", as Rafael suggested? Perhaps. But it's a little misleading, since what these applications are permitted to do is to _prevent_ the system from going to low power. So in a real sense they don't drive PM -- they block it. (Indeed, that's what inspired the name "suspend blocker".) Of course, the same objection applies to "power-permitted". > > I was agreeing with the requirement but disagreeing with the reason > > given for it. Even when buffers are large enough that the danger of > > overrunning them is infinitesimal, delays in input event delivery are > > still undesirable. > > > > Besides, the Android kernel doesn't vary its behavior based on whether > > the recipient is power-permitted or power-naive; it _always_ delivers > > input events in a timely fashion. > > True, the difference between the two classes of applications is in > whether or not the application is permitted to process the event. > > I added "and to minimize response latencies" to the requirement. > Does that capture it? Yes. > > > But leaving that aside, I thought that Arve and Brian explicitly > > > stated this as a requirement on power-aware applications -- one of the > > > responsibilities that came with the power to block suspend. > > > > No. There are _no_ requirements on power-permitted (or power-aware if > > you prefer) applications, other than that the user decides to give it > > the appropriate permission. > > > > Internally, of course, Android may enforce this rule on their own > > software. But it has no force in regard to external applications. > > So should this be moved to a new "ANDROID POLICY" section or some such? Or DESIRED BEHAVIOR, or some such. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/