Android 核心已经从 Linux kernel 代码库中删除

新闻来源:http://www.kroah.com/log/linux/android-kernel-problems.html
As the Android kernel code is now gone from the Linux kernel, as of the 2.6.33 kernel release, I'm starting to get a lot of questions about what happened, and what to do next with regards to Android. So here's my opinion on the whole matter...

First off, let me say that I love the Android phone platform. Until last week, I used my developer G1, that I bought, every day. It worked wonderfully for me, and as a user, I was more than happy.

I'm also very happy about Android from a technical perspective. It's amazing that Google has taken the Linux kernel, and nothing else from a "traditional" Linux system, and created a portable and robust phone platform. It's so different that you can drop in a "real" Linux system image on top of the Android system, and they both work just fine with no changes needed.

Android also solves the problem that the phone manufacturers had been having for many years: a free version of Java and a unified application layer that programmers can write to that will work on all phone platforms that integrate it. Because of this, all of the existing "Linux Phone Consortium" groups are doomed and will probably close up silently very soon now, if they haven't already.

What's wrong?

So, what happened with the Android kernel code that caused it to be deleted? In short, no one cared about the code, so it was removed. As I've stated before, code in the staging tree needs to be worked on to be merged to the main kernel tree, or it will be deleted.

But there's a much bigger problem here.

The Android kernel code is more than just the few weird drivers that were in the drivers/staging/android subdirectory in the kernel. In order to get a working Android system, you need the new lock type they have created, as well as hooks in the core system for their security model.

In order to write a driver for hardware to work on Android, you need to properly integrate into this new lock, as well as sometimes the bizarre security model. Oh, and then there's the totally-different framebuffer driver infrastructure as well.

This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree.

Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on.

Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.

But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.

What would be needed to get the Android core code merged?

When the Android code was merged into the staging tree, a number of kernel developers reviewed the code and pointed out places that needed to be cleaned up, and changed, in order for it to be accepted. A number of these changes will affect the kernel/userspace boundry, so some changes to the Android userspace logic would also need to be changed if these kernel changes are made, preventing anyone except a Google employee from making the changes necessary.

So, what to do?

I really don't know. Google shows no sign of working to get their code upstream anymore. Some companies are trying to strip the Android-specific interfaces from their codebase and push that upstream, but that causes a much larger engineering effort, and is a pain that just should not be necessary.

Hope

I do hold out hope that Google does come around and works to fix their codebase to get it merged upstream to stop the huge blockage that they have now caused in a large number of embedded Linux hardware companies.

I've privately offered in the past to help this work get done, and am doing again here publicly. But I need the help of the Google developers to make it happen, without them, nothing can change.

The good news is that it looks like all of the kernel/userspace api changes will have no affect at all on any Android code higher up the stack (like applications), so all of this work can be done with no problem in the overall system.

I'll be giving a talk about this whole Android mess at the CE Linux Forum 2010 conference. Hopefully it improves before then, otherwise CELF will be continuing the long-held tradition of having keynotes in which the presenter yells at the attendees for all of the bad things they are doing.

评论

6 楼 Elrond 2010-02-10  

momoch1314 写道

假设：
如果Google符合GPL。
把硬件厂商的本身不开源驱动也进行开源的话会有什么后果？
硬件驱动的源码也不属于Google，Google有权利开放吗？

他们得不到驱动源码吧.

那是商业机密

就算得到了也不能开放, 否则就是侵权.

Google的Android平台说白了还是一个致力于统一的平台, 我无法统一硬件, 但是可以统一内核.

5 楼 wafj1984 2010-02-10  

你贴了什么东东啊？  没任何解释？

4 楼 momoch1314 2010-02-05  

假设：
如果Google符合GPL。
把硬件厂商的本身不开源驱动也进行开源的话会有什么后果？
硬件驱动的源码也不属于Google，Google有权利开放吗？

3 楼 wing5jface 2010-02-05  

[Android，开源还是封闭？]
http://www.ruanyifeng.com/blog/2010/02/open_android_or_not.html
[关于 Linux “踢出” Android]
http://www.cnliufeng.com/blog/2010/02/linux-and-android.html

2 楼 BarryWei 2010-02-05  

人家已经说了：

引用

This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree.

1 楼 biAji 2010-02-04  

没什么了不起的。Fedora库那么多孤儿库谁去关心过