On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote: > On Wed, 02 Jun 2010 12:21:28 +0200 > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > Do you switch your pc on and off manually? Sometimes? Really? > (if not, you are probably a kernel hacker *g*) Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace parts, but no, not otherwise ;-) But I've been doing that for pretty much as long as I've had a computer. > But the rest are usecases that are similar to the suspend-blocker > usecases. You know that you are not using the machine and going > through the pain to shut down your machine. You have to do it manually. > Why? Make suspend an idle state and teach apps to go real quiet. (Then again, that only really works when regular network packets can wake the machine for my case). > > This leads to having to sprinkle magic dust (and lots of config options) > > all over userspace. Something that gets esp interesting with only a > > boolean interface. > > A userspace daemon could keep track of what applications can be > ignored. The wordprocessor probably should not keep the system busy. As > well as a running firefox. > > It is a hard problem. But we have _no way of deciding any of this in > the kernel_ Therefore I say, fix the worprocessor to not actually do anything if its not poked at -- not too hard, wordprocessors really don't need to do anything on their own, and you can do your last backup cycle when the window becomes invisible and stop the timer until the document changes again. Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own. Fix the friggin apps, don't kludge with freezing. You really only ever want to freeze broken apps. And even for those I would prefer it if I got notified some app is stupid, then I could either fix it, or choose not to use it. You can also teach cron to listen to dbus messages telling it about the screen state and postpone jobs -- but please make that a configurable thing, I really like all that work done at 4am when I'm (usually) not around to be bothered by it. > The problem is there independently of suspend blockers. If the system > can suspend with network up, then you shure as hell want to suspend > even if the network is up. So it would actually be a reason for any > kind of "suspend blockers" scheme. Wouldn't it? Well, at that point suspend is nothing more than an idle state, and platform code needs to somehow inform the idle state governor that active net connections need to prevent that idle state from being used. If you want to call that suspend blockers, then sure, but its a long way away from the explicit scheme proposed at the start of this thread. -- 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
