Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:47 UTC (Wed) by dlang (guest, #313)
In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by dberlin
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

The ARM people do not like the fact that they have every board ever produced maintained as if it was a separate cpu architecture.

They have a solution in mind for this (a config table to separate the system config from the kernel architecture) and are moving on it.

the proliferation of ARM sub architectures is a major problem.

in the x86 world, imagine that every motherboard was a separate architecture, with devices at different addresses and supporting different features. This actually happened back in the 8086 and 80286 days, but the marketplace demanded compatibility so that things developed for one system could run on others with similar or better capabilities.

in the embedded space, everyone starts off with the idea that the product is a one-off, but linux has now been used long enough that companies are starting to come out with 2nd and 3rd generation products, which take the same basic design, update to current chips, and add new features. In this process they are realizing that there is value in having things standardized, even if it that standardization is just having a standard way to define the non-standard ways that standard components are connected to the system.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 21:04 UTC (Wed) by morrildl (guest, #63330) [Link] (6 responses)

> the proliferation of ARM sub architectures is a major problem.

Boy howdy, you can say THAT again.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 7:38 UTC (Thu) by cdibona (guest, #13739) [Link] (5 responses)

And again. And again. And again, for many years to come.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 20:23 UTC (Thu) by rahvin (guest, #16953) [Link] (4 responses)

But the beauty of getting it all into the Mainline kernel is that switching vendors becomes trivial. And the best part is that you can tell the hardware vendor to do the work to get it into the kernel before you ever even consider using the hardware. Not only can the vendor produce better code for their hardware, but once it's all upstream it's trivial to support if you are using mainline Kernels.

It's a seriously big mistake Google is making by forking. The long term effort will grow exponentially over time until the effort to maintain will exceed the benefit at which point the company will dump the project. If you don't believe me, look at Redhat's financial reports and see how many millions they spend to back port security fixes to kernel versions that are still in their long term support tree. Although the average phone isn't very old there are people that keep them until they break (I've seen 5-6 years old personally). RedHat spends millions keeping 3 year old kernels workable, when you have to support kernels that are that old you will see the real expense of the path you are taking. What I fear is that once you get to that point google will just decide it's not worth it anymore and abandon the whole thing. I actually think that's pretty likely personally.

Your posts make it apparent you don't realize the long term consequence of forking, particularly something as massive and important as the kernel. When Verizon or ATT sues Google for billions because someone used a known security vulnerability in an Andriod kernel that some cracker used to shut down the cellular system (and as a consequence someone couldn't dial 911 and then died) how will you defend the path you've chosen when you sit on the witness stand?

Some clarification on "the Android Kernel"

Posted Feb 7, 2010 8:48 UTC (Sun) by swetland (guest, #63414) [Link] (3 responses)

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

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 23:48 UTC (Wed) by benh (subscriber, #43720) [Link] (1 responses)

Note that we solved that beautifully on PowerPC using the Open Firmware
device-tree model which we generalized to embedded platforms by
disconnecting it from OF itself, and defining a flat representation (ie
self-contained blob) that can be carried around from FW or wrapper to
kernel.

It's a much more powerful approach than everything I've seen done so far for
runtime configuration of the platform.

I know some people are looking at porting to ARM today, we'll see how that
effort goes. It would definitely be a huge improvement.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 0:15 UTC (Thu) by dlang (guest, #313) [Link]

unfortunantly ARM didn't have a standardized firmware to build off of.

that being said, it sounds like what they are trying to move to is very similar, just without the depdnancy on firmware (a device tree that can be passed in as a boot parameter)

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 9:08 UTC (Thu) by mfuzzey (subscriber, #57966) [Link]

>in the x86 world, imagine that every motherboard was a separate architecture, with devices at different addresses and supporting different features.
I work a bit on ARM and I think the problem is somewhat exagerated.
Sure it is complicated compared to x86 but without a common hardware architecture (which I don't see ever coming for embedded devices) its not likely to improve much.

>the proliferation of ARM sub architectures is a major problem.
You don't have a seperate architecture per board but per SoC (or more frequently per SoC family) - for example Freescale iMX21 and iMX27 are very similar and share most of the code.

If your SoC is already supported you only actually have to write one board specific C file, which is basically a set of platform data tables mapping memory addresses, IRQs etc. If the device tree stuff gets merged it will be even easier though not IMHO fundementally different.

>in the embedded space, everyone starts off with the idea that the product is a one-off, but linux has now been used long enough that companies are starting to come out with 2nd and 3rd generation products, which take the same basic design, update to current chips, and add new features.
Yes and that is exactly the reason why following mainline and getting your stuff merged is a good idea.

If you're doing a one shot project with a short lifecycle it may not matter but if you either
a) Support your product for a long time (10+ years in my company's case)
b) Plan on releasing new versions on the same basic design
It gets much easier if you can just rebase to the latest code for each version.

One problem is that the kernel patch submission and review timing may be incompatible with your product release cycle. But that just means that you keep the patches in your local tree while waiting for them to be accepted upstream. This way your local patch stack should diminish over time.