On Fri, 28 May 2010 15:02:37 +0100 > Ok, I think I've misunderstood you. You're actually saying that only > applications that are trusted to behave well are allowed to receive > wakeup events? Yes, that makes implementation significantly easier. If To receive them in a manner that they are permitted to defer a suspend. There is non reason why bouncing cows shouldn't get to see an event, but there is always the miniscule possibility that we choose to suspend as it gets the event. That to me seems fine. Our starting basis was - Bouncing cows is not trusted Android's reaction was - We reserve the right to suspend bouncing cows where it likes it or not The caveat becomes - Bouncing cows may get suspended then get an event when the phone wakes back up. So I might press "Moo" just before a suspend and get the noise when it resumes. Given the untrusted cows could respond to the event otherwise by blocking the suspend for as long as permitted with a suspend blocker or similar that seems no worse. In this case probably better [oof zap! as opposed to 60 seconds of 'event, no sorry got a cow to draw at 100% CPU') As the app is untrusted we can't assume they would get suspend blockers right even if they had any. You can still be nice to the cows app and when the phone is put down send it a 10 second warning via dbus or Android equivalents. Your trusted call handling app can still request (by QoS or big hammers) that the phone does not suspend even if the app goes idle (because you have a wakeup latency QoS) A naïve trusted app will behave according to power management idling to suspend and get stopped A naïve untrusted app that is doing sane things will spend most of its life asleep and behave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
