Some clarification on "the Android Kernel"

Posted Feb 7, 2010 8:48 UTC (Sun) by swetland (guest, #63414)
In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by rahvin
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

There seems to be a lot of confusion here.

We maintain a set of patches on top of Linux, which we periodically rebase to the latest released Linux kernel. We've been doing this roughly every other kernel release since about 2.6.14. This week we're finalizing our move to 2.6.32 for the Android "Froyo" release, and we'll likely be on .33 or .34 for "Gingerbread".

These patches fall roughly into four buckets:
- random bugfixes (these are usually pretty easy to submit upstream)
- generic Android related drivers that are standalone (lowmemorykiller, binder, ashmem, logger, etc): These pieces are used by the Android userspace, but not other kernel drivers.
- generic Android related drivers that add new infrastructure. Wakelocks are pretty much the only significant piece here. They are depended on my peripheral drivers, but that can be conditionalized.
- support for new SoCs (msm7k, msm8k, etc) and boards/devices (G1, myTouch, NexusOne, Droid, etc) - they live under arch/arm/mach-*/... and don't have many special dependencies other than wakelocks (which can be conditionalized)

We've been publishing this code since fall of 2007, when the Android SDK was first released. We try to do almost all our work in the open (for generic drivers and SoC support), with only very product/board specific drivers being delayed until products are announced or shipped.

We certainly would love to get stuff upstream, but it's most useful if we can actually build upstream so it'll work with the Android userspace otherwise we're stucking maintaining patches for that anyway.

We realize, of course, that not everything we do is going to fit with the upstream view of the world, but I think this is a two way street -- being simply told "throw that all out and start over" is perhaps not the best way to encourage people to contribute.

- Brian

Some clarification on "the Android Kernel"

Posted Feb 7, 2010 11:44 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

It is your decision to ship with changes that has not been send upstream
before the product even ships and long after that as well and it is often
the case that if there are userspace dependencies on such out of tree
patches it will come back to bite you

Even now code is being dumped over all the wall in large chunks rather than
doing continuous development in a public maintained branch and this makes
it harder to give early review

Some clarification on "the Android Kernel"

Posted Feb 8, 2010 6:04 UTC (Mon) by swetland (guest, #63414) [Link] (1 responses)

Shipping great products will *always* be higher priority than getting full buy-in from upstream or getting all patches reviewed. There's no way we can tie our ship schedules to an external process like that and accomplish the hard deadlines involved in shipping successful consumer electronics / mobile devices. Realistically, we'll always ship based on at least a couple-month-old kernel due to the time involved in QA, regulatory testing, and qualification for these kinds of devices.

That said, keeping up to date with mainline is extremely important to us -- thus we've rebased many times between 2.6.14 (first internal kernel work) and 2.6.32 (latest), to track mainline, as opposed to sitting on some years-old release forever.

And the best way to keep up to date is just to be in the mainline kernel, so we want to get there and will work to get there, as we can, around other schedule, staffing, etc limitations that often make it difficult.

Some clarification on "the Android Kernel"

Posted Feb 18, 2011 6:00 UTC (Fri) by tchalvak (guest, #72984) [Link]

Thank you for explaining the necessity of your approach. With a goal like android phones in mind, I expect it is certainly necessary to make some compromises, it's just a question of how short the turn-around time can be to compensate for compromises.

I felt compelled to create an account to comment on the unfortunate level of hostility and lack of willingness to start useful, civil dialog ppreviously shown in this thread.

Android (from a user perspective) is a breath of fresh air in the operating system ecosystem, and I eagerly await the day that it becomes integrated more fully with desktop linux, so that everyone gets the benefit of both. I expect willingness to work together on what may be difficult technical solutions is the only thing that will get us there.

--posted via my android phone