On Wed, Aug 04, 2010 at 03:20:04PM -0700, david@lang.hm wrote:

quoted text
> on the other hand, making an application avoid consuming inappropriate  
> background resources helps everywhere. an explicit "don't let the machine 
> sleep" only works if you are trusted by a system that implements this  
> flag.
>
> yes, it is painful to make the change, but the end result is better (and  
> there are more tools out there to figure things out)

Nobody's denying that it's better, but people are saying they want to 
design a platform that's capable of handling the software we have rather 
than the software we'd like to have.

quoted text
> but if you have an application in the mid-level trust situation, go ahead 
> and have it talk to a 'keepalive' daemon that is in the 'trusted' set and 
> let the rest of the app run untrusted. As I noted elsewhere, the 
> keepalive daemon would need very little in the way of resources and can 
> implement much more complex policies than anyone is going to be willing 
> to put in the kernel.

That doesn't work. You'll race with wakeup events.

quoted text
> similar to the current implementation, the arrival of a packet could be  
> counted as activity that keeps the system awake for a bit (your timeout)

How? You're either polling in order to know whether there's network 
activity, or you're having every network packet wake up the policy 
daemon, or you've got something that looks like the kernel side of 
wakelocks.

quoted text
>> Cell networks typically have no background traffic, for obvious reasons.
>
> but don't most new smartphones also connect up to wifi networks? those 
> are FAR from quiet.

Wifi radio typically dwarfs your other power consumption anyway. The 
typical situation is one where you're not attached to a wifi network.

quoted text
> I'm not suggesting running all events through some central server (unless 
> you count the kernel as that server),  I'm saying that the decision that  
> the system is idle and therefor can be stopped should be able to take 
> this infomation into account, and if there's a race here, it should be a 
> race that exists everywhere else, so there should be a general solution, 
> not something specific to one use-case. (and definantly not something 
> that requires all software to be modified and trusted to implement)

You're right. It's a race that exists everywhere else, and it's inherent 
unless you have some handshaking between userspace and the kernel when 
entering suspend. Which is what wakelocks provide. Nobody has proposed a 
solution that works without modifying existing code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
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/