At the risk of sticking my neck out, I think a few of your statements

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 

This would be essentially the same as power-aware && !power_naive, 


On Android this goes somewhat farther.  IIUC, they want hardly anything 
to run while the display is powered off.  (But my understanding could 
be wrong.)

For computers in general, of course, this statement is correct.  The
same is true for any output-only device.  For example, if the audio
speakers are powered off, there is no need to run any application whose

This goes well beyond overrunning buffers!  Events must be delivered in

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.

This is probably also true for power-aware applications having other
needs (e.g., non-input-driven computation).  In general, power-aware
applications must have a mechanism to prevent themselves from being

You mean non-power-aware applications, not power-naive applications.  
But then the statement is redundant; it follows directly from the

No, this is not a requirement.  A power-optimized application would do 
this, of course, by definition.  But a power-aware application doesn't 

The controversy was not over the basic point but rather over the 
detailed meaning of "runnable".  A technical matter, related to the 


For present-day phones this obviously doesn't matter, but if the API is

Alan Stern

--

[ message continues ]

Fair enough!  ;-)



It certainly seems to me that most power-optimized applications would
need to be classified as power-aware to work properly.  But there could
easily be power-aware applications that aren't heavily power-optimized,
for example, such an application might make use of the CPU for operations
that could be handled by a power-efficient hardware accelerator.
Perhaps power-aware is to power-optimized as SMP-safe is to perfectly
optimized for SMP scalability and performance.

Though it seems that heavy power-efficiency optimizations might come



Good point -- I didn't find any example of this in the email threads,

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

Good point!  Would it also make sense to say "events" in general rather


I see your point, but I don't feel comfortable deleting this requirement.
My rationale is that the definition needs some enforcement mechanism,

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


You could well be correct, though the Android guys stated it pretty
strongly.  Seems like the usual memory and mass-storage shortages would
be hard to handle with an unconditional API, though the usual solution

Indeed, at least if the API is not to be stubbed out for all
large systems.  Though it might be possible to make a more-scalable
implementation of this API, especially if larger systems were more

Thank you again for looking this over!

							Thanx, Paul
--

[ message continues ]

I'd slightly prefer these to be called "power-oblvious applications", to
reflect the fact that their authors might not take power management into

Also, there is another type of "power-awareness", related to the ability to
react to power management events signaled, for example, by pm-utils using
dbus protocol (NetworkManager is one such application).  However, the
applications having that ability don't really participate in making a decision
to change the state of the system, while the applications using wakelocks do.

In the wakelocks (or suspend blockers, whatever you prefer to call them) world
no single entity is powerful enough to make the system go into a sleep state,
but some applications and device drivers collectively can make that happen.
The applications using wakelocks not only are aware of system power
management, but also are components of a "collective power manager", so
perhaps it's better to call them "PM-driving applications" or something like

Not really, IMO.  !power_naive means "doesn't use wakelocks" in this context,
while "power-optimized" would mean something like "not only uses wakelocks,

Not really.  Quite a lot of things happen on these systems while the display
is off (let alone the periodic battery monitoring on Nexus One :-)).  They
can send things over the network and do similar stuff in that state.

I think the opposite is true, ie. the display is aggressively turned off


That's correct, although it doesn't seem to apply to any kind of input
events.  For example, on Nexus One the touchscreen doesn't generate wakeup
events (ie. events that wake the system up from a sleep states), so I'm not

Side note.  I'd like to avoid confusing device states with system-as-a-whole
states, so I always prefer to refer to the system-as-a-whole-low-power states
as "system sleep states", while term "low-power state" is reserved for
individual devices.

Also in some cases (ACPI mostly) a "system sleep state" is more than a
"system low-power state", because you ...
[ message continues ]

Right, any PM-driving application can -prevent- the system from entering
a deep sleep state, but no single application can force this -- aside

I agree with this.  A power-optimized application is something that
goes to lengths to minimize its power consumption, regardless of whether

Fair enough.  It appears to me that Android won't suspend if the display





Indeed, some embedded systems are capable of doing quite a lot even when
almost everything, including the CPU and cache, is powered down.

							Thanx, Paul
--

[ message continues ]

That's correct.  In fact, Android uses a special mechanism called "early
suspend" (or similar) to suspend the display and some other devices before the
"real" suspend happens.


The requirement is that power-oblivious applications should not participate
in deciding whether or not to put the system into a sleep state which is pretty

Rather, there should be a mechanism allowing PM-driving applications to do
that, but they are not required to use that mechanism.

Thanks,
Rafael
--

[ message continues ]

Fair enough!  I moved this into a new section that I am currently calling
"SUGGESTED USAGE".

							Thanx, Paul
--

[ message continues ]