Re: [PATCH 1/8] PM: Opportunistic suspend support.

[James Bottomley <James.Bottomley@suse.de>]

On Wed, 2010-05-26 at 13:29 +0300, Pekka Enberg wrote:
> Yup, I don't quite get Arve's argument either. C code can interact
> with Java code (and vice versa) just fine in userspace.

This is an incorrect statement.  It's possible for java to call C via
the JNI, even though there are quite a few gotchas that mean not just
*any* C code can do it (been there, tripped over some of them, although
they were all ultimately ironed out).  It's very difficult for C to call
directly into Java without being specially coded because it involves
creating and managing a JVM (so in general, arbitrary C code can't do
this).  The usual way we do C -> Java is process to process via some
intermediary like RPC or Corba or SOAP (or even JSON) ... which gets
very messy for a mobile device.

On Wed, 2010-05-26 at 12:21 +0200, Peter Zijlstra wrote:
> So provide a C interface to it as well?

The way Android is currently coded, all user space suspend blocks are
handled in Java code at what's called the Frameworks layer (Frameworks
is the Java API for apps) this is also how the suspend permissions are
managed and presented to the user.  The few C applications which block
suspend just manipulate the device directly.

> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
> 
> Or make the suspend manager a C proglet and provide a JNI interface,
> or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't
think that's feasible on a reasonable timescale.  Android does have the
concept of special sockets that can be used to communicate from less to
more privileged processes (it has a very segmented runtime model), so
these might be usable ... they have a drawback that they're essentially
named pipes, so no multiplexing, but one per suspend influencing C
process shouldn't be a huge burden.

James