On Sunday 06 June 2010, Arve Hjønnevåg wrote: > 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: > >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote: ... > > 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. Well, the freezing of the "untrusted" part of user space needs to be triggered somehow in the first place. Whatever mechanism is used for that, there should be a way to tell it to not to freeze the "untrusted" part of user space for a while. Yes, it is similar to wakelocks, but I think it can be implemented entirely in user space. So, in general, the "trusted" app that needs an "untrusted" one to handle stuff will take a "freeze lock" to prevent the power manager from freezing the "untrusted" part of user space (that will also cause it to thaw these tasks if they are frozen at the moment) and will release the "freeze lock" when it's done with its job. You can use timeouts and whatever you like with that and the kernel doesn't have to participate in that (except for carrying out the low-level freezing and thawing of the "untrusted" tasks at the power manager's request). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
