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

[James Bottomley]

On Wed, 2010-05-26 at 18:28 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > 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. 
> 
> It wouldn't need to convert the whole Frameworks layer into C, just
> enough to manage the suspend state.

That's actually what I was saying ... converting the whole frameworks
would be impossible.  I'm saying the suspend state manager is still a
large piece of work.

> Anyway, I think there's been enough arguments against even the concept
> of opportunistic/auto-suspend, and I for one will object with a NAK if
> Rafael send this to Linus.

Well, I suppose that's your prerogative.

> The whole idea of segregating userspace like that, and not letting
> runnable thing run is very ill considered indeed.

OK, so this is an approach difference.  I see it as controlling an
application resource problem, which is similar to quotas on filesystems.
The opinion divide seems to come down to those who think the application
stack has to be fixed before a working device can be released, and those
who want to make the devices work now and supply pressure to fix the
applications as well.

I fail to see how, in an environment where the whole value of the device
is the third party supplied applications that the former view is
reasonable.  I equally fail to see how the latter is achievable without
segregating userspace into trusted and untrusted and taking action to
curb the power consumption of untrusted applications.

Given that I'm in the latter category, I think suspend blockers is a
reasonable solution to an existing problem.  I like Alan's idea of
restricting the API into a single user space program so we contain the
API contamination ... but realistically that's mostly the current
suspend blockers anyway.

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/