Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 18:26 UTC (Wed) by cdibona (guest, #13739)
In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by dlang
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

If you don't like how we architected android, don't complain that the code
isn't being mainlined. You can't have your cake and eat it too. We get it,
you don't like how we put together the kernel for android. We're okay with
that. Other companies coming to you for help is fine, too, you can choose
who you help. Others might see that as an opportunity, but whatever.

That you say (multiple times) that we're working in a vacuum is simply not
true, the Android release code and tried working with the kernel community
starting almost 3 years ago. That it hasn't worked out is hardly only our
'fault'.

Drag: The point of the arm forks comment was that there is clearly
something different going on there. If arm is a morass of forks, maybe ARM
and Linux is a tricky matchup that doesn't look like the normal uses of
Linux and thus makes arm forks hard to reintegrate.

To sum up: I think that Android is an unusual use of Linux that doesn't
match up with what is normally done, and I think that a fork isn't
unwarranted in these cases. I should point out we didn't use glibc ,
either, or a 'standard' VM. We built android.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:05 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

The code could be mainlined if Google were willing to consider that their wakelock approach was
suboptimal and adapt to a more reasonable one. This could be done without breaking existing
userspace interfaces.

I'm not aware of any significant interaction between the Android project and the kernel
developers three years ago - I first checked out the Android kernel git tree a little under two
years ago, which was the first I'd heard of the wakelock infrastructure despite having been
active in the Linux power management arena for rather longer than that.

A little over 18 months ago at LRL USA, Robert Love talked about how Android were keen to
avoid the perception of just dumping code over the wall but didn't really argue with my
suggestion that so far the kernel side of things was effectively that. The wakelock patches were
first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago.
http://lwn.net/Articles/318611/ gives a good overview of how they were received - there's
basically no buy in, even from other developers in the embedded Linux field. The last posting of
them was in May of the same year.

I can't find anything to support your assertion that this has been a long term process - the major
sticking point (ie, wakelocks) were posted for public review a year ago and most of the
substantive issues people had with them weren't addressed at all in the four months of
intermittent discussion that followed. If the entire world suggests that you do something in some
other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia
have managed to obtain the same level of power management without such invasive changes,
so any assertion that wakelocks are required for Android to achieve its goals seem pretty
baseless.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 21:39 UTC (Wed) by dcbw (guest, #50562) [Link] (8 responses)

So just because it comes out of Google, and because you built it, all the technical decisions that Google made without input from non-Google developers are perfect and should just be accepted?

That's seriously arrogant.

Feedback is constructive. Perhaps wakelocks *aren't* the best solution for the problem you're trying to solve. Perhaps other kernel developers have more flexible solutions that solve Google's problem just as well as wakelocks, but solve other people's problems too.

I can't remember significant interaction between Google Android developers and mainline kernel developers before early 2009. Contrast that to Nokia who have been *all over* the kernel upstreaming their OMAP patches for the N8xx and N900.

If wakelocks and binder really are the best solutions to the problem for the Linux kernel, then it wouldn't be hard to justify them as such, right? But that hasn't happened.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 21:53 UTC (Wed) by cdibona (guest, #13739) [Link] (7 responses)

No, that is exactly not what I am saying. See my other posts.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 21:59 UTC (Wed) by dcbw (guest, #50562) [Link] (6 responses)

"I think if the Android kernel were important enough to the mainline, then
this wouldn't be a problem."

i.e. just because millions of users are using it mainline should ignore technical considerations and just take the code? That seems pretty wrong...

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 22:17 UTC (Wed) by cdibona (guest, #13739) [Link] (5 responses)

I don't see how that is wrong or arrogant. Let me break it down:

if: Android mattered more to the mainline maintainters.
then: We'd get more attention from them or they'd change their practices.

Nowhere in there did I say we were that important to them.

And be careful flinging around numbers, we have many many millions of handsets, too. It's not about that. It's about what is best on one side for the mainline kernel (and androids mods may not be that) and what is best for the people with androids in their pockets, and indeed whether it matters to harmonize the two.

If you read arrogance in that, that wasn't the intent.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 22:27 UTC (Wed) by dcbw (guest, #50562) [Link] (2 responses)

I actually did mean "millions of Android users", not millions of mainline kernel users.

The arrogance comes from expecting the kernel developers to ignore technical considerations just because there are millions of users of your code.

While having millions of users may mean it works, it may not be the best solution for the problem, for upstream *or* for your users. You may find that the solutions proposed by the kernel developers also make your life easier through easier maintenance of the code and cleaner subsystems when you have to enhance them in the future.

But you have to be /open/ to the possibility that wakelocks may not be the best solution to the problem, instead of proposing that kernel developers just accept them as-is even though they are (in the opinion of some very knowledgable upstream developers) technically faulty.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 19:25 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

I'm glad the Android developer posted. He's conveyed something I didn't realize, that is that Google and their developers believe they are right regardless of what others think. It sounds like this might be a corporate problem in that they truly believe they are right and everyone else is wrong.

I don't think anyone would argue that in some instances it's better to be out of tree than in, but it's the exception, not the rule. Part of getting into mainline is listening to other people when they tell you your code is garbage and your solution is the wrong one and that a better one exists. This is especially true when the other people doing the same kind of development (embedded in this case) tell you that your approach is the wrong one as otherwise you might have an argument that what you propose is an embedded specific exception.

It's an eyeopener to me to see how arrogant the Google developers are about their code. It explains their toss it over the wall attitude precisely. I have to wonder how long Google will be able to maintain this attitude with all the other players in the Open Handset Alliance, and most particularly what will happen when Google gets tired of Android and abandons it. It's unfortunate this attitude exists, while the corporation is interested in Android it will raise their costs significantly and when they abandon it if others haven't forked the code it will die. Rather unfortunate, but as I said, it's probably a corporate problem that in the long term will see most Google code abandoned, rather unfortunate but I guess that's what happens when you can't play with others or take constructive criticism. There is an interesting sociological question on where such corporate attitudes develop and whether they are related to some demographic figure, such as average age, of the Google developers plays a role.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Oct 3, 2011 18:02 UTC (Mon) by tbird20d (subscriber, #1901) [Link]

But lots of embedded developers, me included, think that Android has some nice stuff, that is being blocked from mainline by stubborn-ness, ignorance and pride, rather than any substantive technical issues.

The 'they come to us' attitude

Posted Feb 4, 2010 4:42 UTC (Thu) by eparis123 (guest, #59739) [Link]

then: We'd get more attention from them ..

The linux kernel development model (or any large FOSS development model thereof) depends on initiation from the patches authors, not from 'them', the community.

I'm sorry if this sound rude, but Al Viro once commented here as I remember that the community perceives the 'they come to us' attitude as a sign of arrogant developers.

.. or they'd change their practices.

You don't really join a community by asking it to change its practices firsthand! I guess this is really obvious

"If Android code was important to the mainline kernel..."

Posted Dec 9, 2010 10:37 UTC (Thu) by dneary (guest, #55185) [Link]

Replying to a really old comment... don't know if that's good or bad LWN etiquette.

To turn this phrase on its head, one could argue that:

If getting code upstream was important to Android developers:
Then they would expend more effort in accommodating concerns that the kernel developers have raised about the patches

No-one likes to maintain someone else's abandoned code.

I only bring this up now because of a recent announcement which reads like a regression to me: http://source.android.com/source/code-lines.html (that said, it has the advantage of clarifying expectations, which I applaud).

Cheers,
Dave Neary.