[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Florian Mickler on 26 May 2010 09:10 On Wed, 26 May 2010 14:41:29 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: > > On Wed, 26 May 2010 15:29:32 +0300 > > Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > > > > > hi, > > > > > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: > > > >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. > > > > > > What I find ridiculous is the assumption that kernel should provide good > > > power management even for badly written applications. They should work, > > > of course, but there's no assumption that the kernel should cope with > > > those applications and provide good battery usage on those cases. > > > > > > You can install and run anything on the device, and they will work as > > > they should (they will be scheduled and will be processed) but you can't > > > expect the kernel to prevent that application from waking up the CPU > > > every 10 ms simply because someone didn't think straight while writting > > > the app. > > > > > > > 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. > > Provide the developers and users with tools. > > Notify the users that their phone is using power at an unadvised rate > due to proglet $foo. > > Also, if you can integrate into the development environment and provide > developers instant feedback on suckage of their app they can react and > fix before letting users run into the issue. > Yeah. And I personally agree with you there. But this is a policy decision that should not prevent android from doing it differently. The kernel can not win if it does not try to integrate any use of it. After all, we are a free comunity and if someone wants to use it their way, why not allow for it? (As long as it does not directly impact other uses) The best solution wins, but not by decision of some kernel development gatekeepers, but because it is superior. There are no clear markings of the better solution. Time will tell. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 26 May 2010 09:10 On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: > The kernel can not win if it does not try to integrate any use of it. If we'd integrate every patch that came to lkml, you'd run away screaming. We most certainly do not want to integrate _any_ use. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 26 May 2010 09:20 > 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. That seems to me to be conflating models of behaviour and implementations. > This is a _big_ plus for attracting 3rd party programs. (And of course > the thing you don't like). You would do better to concentrate on technical issues that the assignment of malicious intent to other parties. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 26 May 2010 09:20 On Wed, 26 May 2010 14:55:31 +0200 Vitaly Wool <vitalywool(a)gmail.com> wrote: > On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian(a)mickler.org> wrote: > > > 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. > > You almost always need to "hack" the mainline software for a > production system. So do it here as well. Make sure the hack is well > isolated and local. You can even submit it to the mainline, better as > a configuration option, _unless_ it is a *framework* that provokes > writing code in an ugly and unsafe way. > > ~Vitaly I don't think that the in-kernel suspend block is a bad idea. You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not. Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a "suspend as soon as possible" semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away). Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 26 May 2010 09:40
On Wed, 26 May 2010 15:07:27 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote: > > The kernel can not win if it does not try to integrate any use of it. > > If we'd integrate every patch that came to lkml, you'd run away > screaming. > > We most certainly do not want to integrate _any_ use. We most certainly do want to integrate any use that is not harmful to others. I don't buy the argument that this is harmful. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |