2010/6/6 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: >> > >> > Can you please explain in a consistent way how the application stack >> > and the underlying framework (which exists according to android docs) >> > is handling events and how the separation of trust level works ? >> > >> >> I don't think I can, since I only know small parts of it. I know some > > Sigh, thats the whole reason why this discussion goes nowhere. > Please keep in mind that we also have third party applications and that it is not acceptable to break them. So even if I was able to tell you everything our framework does, you still need to make sure your solution does not break existing apps. > How in heavens sake should we be able to decide whether suspend > blockers are the right and only thing which solves a problem, when the > folks advocating suspend blockers are not able to explain the problem > in the first place ? > >> events like input event go though a single thread in our system >> process, while other events like network packets (which are also >> wakeup events) goes directly to the app. > > Yes, we know that already, but that's a completely useless information > as it does not describe the full constraints and dependencies. > > Lemme summarize: > > Android needs suspend blockers, because it works, but cannot explain > why it works and why it only works that way. > > A brilliant argument to merge them - NOT. > Your solution changes the programming model in a way that suspend does not. Linux allow processes to communicate with each other, and if you freeze individual processes this breaks. For the android framework code a lack of a timely response from an application is treated as an error, and the user is notified that the application is misbehaving. It may be possible to change the framework to make sure that no processes are frozen while it is waiting for a response, but this is a major change and applications that receive wakeup events directly from the kernel will still be broken. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
