Date:	Sun, 6 Jun 2010 02:32:51 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
> >> > 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.

Thanks,

	tglx
 

Powered by blists - more mailing lists