Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758730Ab0HECjq (ORCPT ); Wed, 4 Aug 2010 22:39:46 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:42280 "EHLO e8.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758717Ab0HECjo (ORCPT ); Wed, 4 Aug 2010 22:39:44 -0400 Date: Wed, 4 Aug 2010 19:39:39 -0700 From: "Paul E. McKenney" To: Arve =?iso-8859-1?B?SGr4bm5lduVn?= Cc: Matthew Garrett , "Rafael J. Wysocki" , david@lang.hm, Arjan van de Ven , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, pavel@ucw.cz, florian@mickler.org, stern@rowland.harvard.edu, swetland@google.com, peterz@infradead.org, tglx@linutronix.de, alan@lxorguk.ukuu.org.uk Subject: Re: Attempted summary of suspend-blockers LKML thread Message-ID: <20100805023939.GA2987@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20100801054816.GI2470@linux.vnet.ibm.com> <20100804185520.GA2417@srcf.ucam.org> <201008042251.08266.rjw@sisk.pl> <20100804205654.GA4986@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1275 Lines: 27 On Wed, Aug 04, 2010 at 03:08:33PM -0700, Arve Hj?nnev?g wrote: > On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett wrote: [ . . . ] > > having this conversation? :) It'd be good to have some feedback from > > Google as to whether this satisfies their functional requirements. > > That is "this"? The merged code? If so, no it does not satisfy our > requirements. The in kernel api, while offering similar functionality > to the wakelock interface, does not use any handles which makes it > impossible to get reasonable stats (You don't know which pm_stay_awake > request pm_relax is reverting). The proposed in user-space interface > of calling into every process that receives wakeup events before every > suspend call is also not compatible with existing apps. I should have asked this earlier... What exactly are the apps' compatibility constraints? Source-level APIs? Byte-code class-library invocations? C/C++ dynamic linking? C/C++ static linking (in other words, syscall)? Thanx, Paul -- 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/