> > > o	"Power-aware application" are applications that are permitted
quoted text
> > > 	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.
> > 
> > Notice that these definitions allow a program to be both power-naive
> > and power-aware.  In addition, "power-awareness" isn't an inherent
> > property of the application itself, since users are allowed to decide
> > which programs may exert control over the system's power state.  The 
> > same application could be power-aware on one system and non-power-aware 
> > on another.

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.

quoted text
> > > REQUIREMENTS
> > > 
> > > o	Reduce the system's power consumption in order to (1) extend
> > > 	battery life and (2) preserve state until AC power can be obtained.
> > 
> > External power, not necessarily AC power (a very minor point).
> 
> A good one, though.

Arjan's point here is well taken.  Even systems that always run on
external power have motivation for conserving energy (e.g., they may
be required by government regulation to do so).

quoted text
> > > o	In order to avoid overrunning hardware and/or kernel buffers,
> > > 	input events must be delivered to the corresponding application
> > > 	in a timely fashion.  The application might or might not be
> > > 	required to actually process the events in a timely fashion,
> > > 	depending on the specific application.
> > 
> > This goes well beyond overrunning buffers!  Events must be delivered in
> > a timely fashion so that the system isn't perceived to be inoperative.
> 
> Agreed for power-aware applications.  For power-naive applications,
> the last event delivered can be buffered by the application with no
> response if I understand correctly.  If there is a subsequent event
> for that same application, then the prior event can be processed.

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.

quoted text
> > > o	If a power-aware application receives user input, then that
> > > 	application must be given the opportunity to process that
> > > 	input.
> > 
> > A better way to put this is: The API must provide a means for
> > power-aware applications receiving user input to keep themselves
> > running until they have been able to process the input.
> 
> Good point!  Would it also make sense to say "events" in general rather
> than "input" in particular?

Sure.

quoted text
> > > o	Power-naive applications must be prohibited from controlling
> > > 	the system power state.  One acceptable approach is through
> > > 	use of group permissions on a special power-control device.
> > 
> > You mean non-power-aware applications, not power-naive applications.  
> > But then the statement is redundant; it follows directly from the
> > definition of "power-aware".
> 
> I see your point, but I don't feel comfortable deleting this requirement.
> My rationale is that the definition needs some enforcement mechanism,
> and this requirement is calling out the need for such a mechanism.

Then state it immediately after the definition as an implication of
the definition, not as a separate system requirement.

quoted text
> > > o	When a power-aware application is preventing the system from
> > > 	shutting down, and is also waiting on a power-naive application,
> > > 	the power-aware application must set a timeout to handle
> > > 	the possibility that the power-naive application might halt
> > > 	or otherwise fail.  (Such timeouts are also used to limit the
> > > 	number of kernel modifications required.)
> > 
> > No, this is not a requirement.  A power-optimized application would do 
> > this, of course, by definition.  But a power-aware application doesn't 
> > have to.
> 
> I am not sure we agree on the definition of "power-optimized application".
> 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.

quoted text
> > > o	If no power-aware or power-optimized application are indicating
> > > 	a need for the system to remain operating, the system is permitted
> > > 	(even encouraged!) to suspend all execution, even if power-naive
> > > 	applications are runnable.  (This requirement did appear to be
> > > 	somewhat controversial.)
> > 
> > The controversy was not over the basic point but rather over the 
> > detailed meaning of "runnable".  A technical matter, related to the 
> > implementation of the scheduler.
> 
> OK, what would you suggest for the wording of this requirement?

Change the last phrase to "regardless of the state of power-naive
applications".

Alan Stern

--
unsubscribe notice
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/