> Really, what are you getting at? Do you deny that there are programs, > that prevent a device from sleeping? (Just think of the bouncing > cows app) > > And if you have two kernels, one with which your device is dead after 1 > hour and one with which your device is dead after 10 hours. Which would > you prefer? I mean really... this is ridiculous. The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else" The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores. That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ? - You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this - You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1] That maps onto two existing ideas Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like setpidle(getpid(), something); exec() where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API. And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone. Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers. Alan -- [1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. "Static" simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states) -- 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
