On Sat, 5 Jun 2010, Florian Mickler wrote: > On Sat, 5 Jun 2010 23:26:27 +0300 > Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > > Supposing there's a perfect usage of suspend blockers from user-space > > on current x86 platforms (in theory Android would have that), is the > > benefit that big to consider this a strong argument in favor of > > suspend blockers? Considering the small amount of x86 platforms using > > Android (is there any?), the fact that nobody else will use suspend > > blockers, and that x86 is already being fixed (as mentioned many times > > before) so dynamic PM is possible, I don't think we should be > > considering current x86 at all for suspend blockers. > > A solution for the desktop to deprecate having to shut down the > machine would not be that bad, wouldn;t it? (Why have I to shut down > my machine anyway?) > > In my opinion such a decision (when to shutdown) has to be guided by > userspace knowledge. > Future x86 hardware is to be fixed (as I read in this discussion), so > using suspend blockers could be the tool of choice. > > But alright. Let's be a little bit more focused on the present > situation: > > 1) There currently is no other solution. Wrong. The solutions are there, just being refused. > 2) It is a first stepping stone to bringing android to mainline. Crap. Once we have an userspace API we are bound to it. Period. Also there is no technical reason why the whole driver stack cannot be merged w/o the suspend blockers. > 3) Any "perfect" solution will emerge anyway. As there are so many > people with so strong opinions engaged in this discussion, I'm > confident. Yes, and that needs cooperation and compromises from both sides and not just blindly defining that there is no other solution. > 4) If there is a better solution, android will shurely adapt it as > soon as it is there. Sure, after we accepted the crap there is no incentive at all. Stop that advertising campaing already. No thanks, tglx -- 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
