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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
