[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274879177.27810.386.camel@twins>
Date: Wed, 26 May 2010 15:06:17 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Florian Mickler <florian@...kler.org>
Cc: felipe.balbi@...ia.com, Vitaly Wool <vitalywool@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
"Paul@...p1.linux-foundation.org" <Paul@...p1.linux-foundation.org>,
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 Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:
> 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.
That's exactly what we always do. If we were not to do so, the kernel
would be a bloated incoherent piece of crap.
> So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.
> 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.
I really think we should not do so. Let them help in fixing the real
issue instead of creating a new class of userspace that is more
important than another.
> 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".
How is userspace without suspend blockers not accountable? We can easily
account runtime and in fact have several ways to do so.
--
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