Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751963Ab0FCGnN (ORCPT ); Thu, 3 Jun 2010 02:43:13 -0400 Received: from smtp-out.google.com ([74.125.121.35]:16487 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054Ab0FCGnJ convert rfc822-to-8bit (ORCPT ); Thu, 3 Jun 2010 02:43:09 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=GcUADVHyLKH8ImCY2v/bnrB1iuVBKbNyHtH7fL45ytXQlxnv2s0KeksjTMOV44M1Q IGjYBZueSzINfEnRU8cPw== MIME-Version: 1.0 In-Reply-To: <20100603163307.721b1c23@notabene.brown> References: <201006010005.19554.rjw@sisk.pl> <20100601090023.788cabf4@notabene.brown> <201006010232.20263.rjw@sisk.pl> <20100601113309.609349fd@notabene.brown> <20100601122012.1edeaf48@notabene.brown> <20100602153235.340a7852@notabene.brown> <20100602180614.729246ea@notabene.brown> <20100603163307.721b1c23@notabene.brown> Date: Wed, 2 Jun 2010 23:43:06 -0700 Message-ID: Subject: Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) From: Brian Swetland To: Neil Brown Cc: =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , "Paul@smtp1.linux-foundation.org" , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1588 Lines: 31 On Wed, Jun 2, 2010 at 11:33 PM, Neil Brown wrote: >> >> The current suspend-blocker proposal already involves userspace >> changes (it's different than our existing wakelock interface), and >> we're certainly not opposed to any/all userspace changes on principle, >> but on the other hand we're not interested in significant reworks of >> userspace unless they actually improve the situation somehow.  I think >> bottlenecking events through a central daemon would represent a step >> backwards. > > I guess it becomes an question of economics for you then.  Does the cost of > whatever user-space changes are required exceed the value of using an upstream > kernel?  Both the cost and the value would be very hard to estimate in > advance.  I don't envy you the decision... Well, at this point we've invested more engineering hours in the various rewrites of this (single) patchset and discussion around it than we have spent on rebasing our trees on roughly every other mainline release since 2.6.16 or so, across five years of Android development. We think there's some good value to be had (all the usual reasons) by heading upstream, so we're still discussing these patches and exploring alternatives, but yes, from one way of looking at it, it'd certainly be cheaper to just keep maintaining our own trees. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/