Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933938Ab0FFBqB (ORCPT ); Sat, 5 Jun 2010 21:46:01 -0400 Received: from mail-pv0-f174.google.com ([74.125.83.174]:63849 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933768Ab0FFBp7 convert rfc822-to-8bit (ORCPT ); Sat, 5 Jun 2010 21:45:59 -0400 MIME-Version: 1.0 In-Reply-To: References: <20100603193045.GA7188@elte.hu> <20100603232302.GA16184@elte.hu> <1275644619.27810.39462.camel@twins> <201006050138.30859.rjw@sisk.pl> Date: Sat, 5 Jun 2010 18:45:58 -0700 Message-ID: Subject: Re: suspend blockers & Android integration From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Thomas Gleixner Cc: "Rafael J. Wysocki" , Peter Zijlstra , Ingo Molnar , tytso@mit.edu, Brian Swetland , Neil Brown , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3461 Lines: 79 2010/6/5 Thomas Gleixner : > On Sat, 5 Jun 2010, Arve Hj?nnev?g wrote: >> 2010/6/5 Thomas Gleixner : >> > On Sat, 5 Jun 2010, Arve Hj?nnev?g wrote: >> >> 2010/6/5 Thomas Gleixner : >> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hj?nnev?g wrote: >> >> Cross app calls do not go through a central process. >> > >> > It's not about a central process, it goes through your framework, >> > which should be able to deal with it. If not, it's a design failure >> > which needs to be fixed at the place where the failure happened. >> > >> >> >> >> >> >> How can it be fixed? The user presses the back button, the framework >> >> >> determines that app A is in the foreground and send the key to app A, >> >> >> app A decides that it it does not have anything internal to go back to >> >> >> and tells the framework to switch back to the previous app. If the >> >> >> user presses the back key again, the framework does not know which app >> >> >> this key should go to until app A has finished processing the first >> >> >> key press. >> >> > >> >> > Errm, what has this to do with frozen apps? If your system is >> >> > handling input events then there are no frozen apps and even if they >> >> > are frozen your framework can unfreeze them _before_ talking to them. >> >> > >> >> > So which unfixable problem are you describing with the above example ? >> >> > >> >> >> >> You are claiming that trusted code should not have any dependencies on >> >> untrusted code. I gave you a visible example of such a dependency and >> >> want you to tell me how you can avoid this dependency. Since you are >> >> claiming that our user-space framework is fundamentally broken if it >> >> has to wait for untrusted code, I don't think it is unreasonable for >> >> you to answer this. Or do you think it is valid to communicate with >> >> untrusted code when the screen is on but not when it is off. >> > >> > It does not matter whether the screen is off or not. If you need to >> > call into that untrusted app from your trusted app and you know about >> > the might be frozen state then you can deal with it. >> > >> > So taking your example: >> > >> > Event happens and gets delivered to the framework >> > >> > ? ? ?framework selects A because it is in the foreground >> > >> > ? ? ?if (A is frozen) >> > ? ? ? ? unfreeze(A) >> > >> > ? ? ?deliver_event_to(A) >> > >> > It's that simple. >> > >> >> That is too simple. You also have to prevent A from being frozen while >> it is processing the event or the result would be the same as if it >> was frozen beforehand. > > The framework decides when to freeze the app in the first place (as > your framework does now when it decides to suspend) > > ? ? So it knows whether the app is frozen or not. > > ? ? So it knows damend well whether it processed the event or not. > Our user-space code is not single-threaded. So just because an app was not frozen when you checked does not mean it will remain unfrozen. We can use the same user-space wakelock api we have now to prevent freezing apps instead of preventing suspend, but we loose any advantage we get from freezing just a subset of processes this way. -- Arve Hj?nnev?g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/