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

From: James Bottomley
Date: Wed May 26 2010 - 13:40:25 EST


On Wed, 2010-05-26 at 20:25 +0300, Pekka Enberg wrote:
> Hi James,
>
> 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.
>
> On Wed, May 26, 2010 at 7:18 PM, James Bottomley
> <James.Bottomley@xxxxxxx> wrote:
> > 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.
>
> Incorrect statement how exactly? A JVM can do mmap(), for example,
> just fine through FileChannel.map() so there's no need for
> heavy-weight RPC.

Incorrect in that an arbitrary C application can't link to a java API.
mmap and some other messaging (like signals) is just another form of
IPC ... the list I gave wasn't exhaustive.

> Furthermore, the whole discussion is moot anyway as
> Android runs Dalvik which can be hacked to support whatever
> communication mechanism is the best choice here.
>
> So can we drop the whole "we need to do it in kernel because Java is
> hard" nonsense and concentrate on real issues?

I've lost you. This argument seems to hinge on whether or not you
believe that suspend in any form is a solution to the rogue app
problem ... whether it's implemented in Java or C is an ancillary issue.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/