On Wed, 26 May 2010 15:35:32 +0300 Felipe Balbi <felipe.balbi@xxxxxxxxx> wrote: > Hi, > > On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: > >But then someone at the user side has to know what he is doing. > > > >I fear, if you target mass market without central distribution > >channels, you can not assume that much. > > and that's enough to push hacks into the kernel ? I don't think so. Do > it like apple and prevent multi-tasking for any non-apple applications > :-p > :) It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. All points about the impact on the kernel have already been raised. So you should be happy there. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel. And as for the quality of the "hack": I think you find this ugly, just because you don't like the concept of degrading user space guaranties on timers and stuff. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource "power". If a user space program needs the "traditional" guaranties for functioning properly, it needs to take a suspend blocker. But _THEN_ it better be well behaved. This is a kind of contract between userspace and kernelspace. On the other hand, if I don't need these traditional guaranties on timers and stuff, I don't have to know device specific things about power consumption. I can just use whatever facilities the programming language provides without needing to worry about low level details. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). Cheers, Flo _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
