[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100527220314.312d9e3c@lxorguk.ukuu.org.uk>
Date: Thu, 27 May 2010 22:03:14 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Arve Hjønnevåg <arve@...roid.com>,
Florian Mickler <florian@...kler.org>,
Vitaly Wool <vitalywool@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Paul@...p1.linux-foundation.org, felipe.balbi@...ia.com,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> >
> > > If that's what you're aiming for then you don't need to block
> > > applications on hardware access because they should all already have
> > > idled themselves.
> >
> > Correct, a well behaved app would have. I thought we all agreed that
> > well behaved apps weren't the problem?
>
> Ok. So the existing badly-behaved application ignores your request and
> then gets blocked. And now it no longer responds to wakeup events. So
> you penalise well-behaved applications without providing any benefits to
> badly-behaved ones.
I don't see how you put the first two sentences together and get the
final one.
When you beat up badly behaved apps that doesn't penalise well behaved
ones.
Forcing "well behaved apps" to make hundreds of extra calls to a complex
blocker interface that also requires tons of kernel code and requires the
application know platform policy and be recompiled if it changes - now
that is punishing well behaved apps.
A well behaved app should just work using standard existing APIs because
that is how all the standard current well behaved apps are written [1].
Alan
--
[1] I'm dying to see the suspend blocker patch for evolution ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists