On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa@xxxxxxxxx> wrote: > > What I consider plain wrong i to claim that since there are this many units > out, some code should be merged. I've never suggested that we should get a get-out-of-code-review-free card or be automatically merged based on shipping volume. Hell, I never thought we should even bother trying to merge wakelocks upstream, because I assumed that they'd be hated for not being the linux way (tm). Greg KH and others have spent a bunch of time shouting at me (or Google) that we should be doing this, and here we are giving it a go. At this point we've spent more engineering time on revising this one patchset (10 revisions to address various rounds of feedback) and discussion of it than we have on rebasing our working kernel trees to roughly every other linux release from 2.6.16 to 2.6.32 (which became much easier after switching to git). > A company needs to cut corners sometimes when making a product but this > should not affect upstream code. I will disagree that wakelocks are "cutting corners" (we certainly have some corner cutting code in our trees, because yeah, ship is compromise, but I don't believe wakelocks are an example). They're a real solution for real problems faced on real devices. Obviously not a solution that everyone here likes, and maybe they'll never end up in mainline as a result, but so far I haven't seen a counter proposed solution that seems to solve the same problem, avoid races, and be simpler/cleaner (at least to my eyes). >> I am quite willing to state that on both MSM and OMAP based Android >> platforms, we've found that the suspend blocker model allows us to >> obtain a lower average power draw than if we don't use it -- Mike Chan >> provided some numbers earlier in another thread in the trivial device >> idle case, the win is of course much larger in the case of several >> poorly behaved apps being active. > > That's very good. But if it is done in a conceptually flawed way, some > better solution should be considered for upstream merge. How is it flawed? Serious question. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
