On Wed, Aug 04, 2010 at 07:46:56PM -0700, Brian Swetland wrote: > 2010/8/4 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>: > > 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@xxxxxxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
