[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100805040532.GB2491@linux.vnet.ibm.com>
Date: Wed, 4 Aug 2010 21:05:32 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Brian Swetland <swetland@...gle.com>
Cc: Arve Hjønnevåg <arve@...roid.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, david@...g.hm,
Arjan van de Ven <arjan@...radead.org>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
pavel@....cz, florian@...kler.org, stern@...land.harvard.edu,
peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread
On Wed, Aug 04, 2010 at 07:46:56PM -0700, Brian Swetland wrote:
> 2010/8/4 Paul E. McKenney <paulmck@...ux.vnet.ibm.com>:
> > 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 <mjg59@...f.ucam.org> 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)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. Changing the basic kernel<->userspace interface (within
> reason) is not unthinkable. For example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use. We'd have to make some userspace changes to
> support that but they're pretty low level and minor.
>
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue). A model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view. We
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
Thank you for the info!
Thanx, Paul
--
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