[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:50 On Wed, 26 May 2010 14:19:42 +0100 Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > 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 This was nothing the kind of! He explicitly said this: On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > 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. And I responded that if the kernel would do this, then that would be a "_big_ plus for attracting 3d party programs". I had no intent in attacking anyone or putting word's in someones mouth. Sorry if this was unclearly written. 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: Alan Stern on 26 May 2010 10:40 On Wed, 26 May 2010, Florian Mickler wrote: > 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. That's not how it works. Drivers aren't supposed to abort unconditional suspend -- not without a really good reason (for example, the device received a wakeup event before it was fully suspended). In short, suspends should be considered to be _always_ possible. > 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). That's different. Suspend blockers could block (not abort!) regular suspends, just as they do opportunistic suspends. But why should they? I mean, if userspace wants to initiate a suspend that is capable of being blocked by a kernel suspend blocker, then all it has to do is initiate an opportunistic suspend instead of a normal suspend. Alan Stern -- 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 11:20 On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: > I'm not saying that your argument is not valid. But why don't you look > at suspend blockers as a contract between userspace and kernelspace? An > Opt-In to the current guarantees the kernel provides in the non-suspend > case. That's backwards. -- 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 11:20 On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: > If you don't want to suspend while > looking at the bouncing-cow, you have to take a suspend blocker and > make yourself a user-visible power-eater, or don't do > > echo "opportunistic" > /sys/power/policy > How about we don't merge that junk and don't give you the opportunity to do silly things like that? :-) -- 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: Kevin Hilman on 26 May 2010 11:30
Alan Cox <alan(a)lxorguk.ukuu.org.uk> writes: > [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) Completely agree with this. I used the static/dynamic names out of habit, but since on most embedded devices, there is really no difference in hardware power state, I agree that the difference is only a matter of wakeup latency. Kevin -- 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/ |