On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar <mingo@xxxxxxx> wrote: > > Sadly the response from the Android team has been 100% uncompromising: either > suspend blockers or nothing. Well, we're willing to accept something that gives us the same functionality (thus rewriting the api several times to meet various objections, current discussions around constraint-based-implementations / pm-qos, etc). We believe we're solving a real problem here and have not seen a counter-proposal that accomplishes the same. Suggestions such as "just yell at developers for writing bad apps" or "it's the user's fault if they install a lousy app" or "make your app marketplace more restrictive" are not helpful. The technical discussions around alternatives are more so (though I do feel like we're going in circles in places), which again is why we're still here talking about this (that and Arve is about a billion times more patient and persistent than I am). We're not interested in massively rearchitecting our userspace to accomplish this (and the "rewrite your userspace!" proposals I've seen have had race conditions and/or significant more complexity than the wakelock model). ... > Also, why did the Android team start its contributions with such a difficult > and controversial kernel feature? We started here because it's possibly the only api level change we have -- almost everything else is driver or subarch type work or controversial but entirely self-contained (like the binder, which I would be shocked to see ever hit mainline). Assertions have been made that because the "android kernel" (not a term I like -- linux is linux, we have some assorted patches on top) has this feature it represents a difficulty for silicon vendors trying to support both Android projects and OEMs and mainline: See: http://www.kroah.com/log/linux/android-kernel-problems.html and various other rants about the evil terrible android forks, etc. So, we figure, let's sort out the hard problem first and then move on with our lives. > There is absolutely _zero_ technical reason why the Android team should > present this as as an all-or-nothing effort. Why not merge hw drivers first > (with suspend blockers commented or stubbed out), to reduce the fork distance? If that's the case then there is no problem and people could stop yelling at us and just submit their drivers. Awesome. I can't speak for all the nameless silicon vendors Greg represents, that we apparently are preventing from doing this (how? I don't know!), etc, but for my team maintaining multiple versions of drivers is a headache, we'd rather square away the wakelock debate first and figure something out there, as it just seems like a more logical approach. Maybe we're crazy. > Really, i myself have controversial kernel features pending all the time. They > dont go upstream for a few kernel releases - over a year sometimes - and > sometimes they never go upstream. > > But the fact that some feature of mine is pending doesnt give me the right to > go away sulking, it doesnt mean i will block the whole flow of patches in > retaliation (as you seem to suggest Google will now have the right to do) - i > simply try to work it out. We're not blocking anything. Hell, if people want drivers we wrote upstream and we're not fast enough for 'em, we publish everything via android.git.kernel.org, pretty aggressively rebase to follow latest mainline, and release everything under GPLv2, ready-to-go. We have to ship though, and as long as the version we maintain has the features we need to ship and the mainline version doesn't, we're going to ship based on our version, but this really shouldn't be surprising to anyone. > Lets be reasonable and work it all out, ok? We're trying. I do feel like we're suffering from lack of a clear "how do we move forward" path, and in particular from an environment where every time we do a bunch of work to address one set of concerns and entirely new set of people pop up with different concerns (sometimes contradicting the last round of changes we were asked to make, etc, etc). Brian -- 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
