Android and kernel community -- Greg kroah-Harman instructions on Android code removal)

From Linux kernel monkey log | translated by Li Yun. For more information, see the ifanr translation link.

Version 2.6.33 removed andirod's code from the kernel. Many people keep asking me what happened and what to do next for Android. Here is my clarification on the whole thing:

First, I like the Android platform very much. Until last week, I used my development mobile phone G1 every day. It works well and I am very satisfied as a user. I also like him technically. Surprisingly, Google only uses the Linux kernel to build a portable and robust mobile phone platform, rather than anything else in the traditional Linux. Even more valuable, you can install a "real" Linux image on the Android system. Both of them can work normally without any modification.

Android also solves the problems that mobile phone manufacturers have encountered over the years: it creates a free Java virtual machine and a unified application software layer, allowing the program to run on all the mobile platforms integrated with it. Because of its appearance, all existing "Linux phone Association" ("Linux phone Consortium") organizations are terminated or are about to close.

What's wrong?

What causes the android kernel code to be deleted? Simply put, no one cares about the code, so he is deleted. As I stated earlier, the code of the Development Branch must be modified to be merged into the kernel Main Line kernel tree. Otherwise, the code will be deleted. However, there are more serious problems here. The android code is not just some drivers in the drivers/staging/Android directory. For the normal operation of the Android system, a new kernel lock created by Google and the hooks in the core system on which the security model lock depends are required ). To write a driver that can be executed on Android, You need to properly use the new kernel lock and sometimes use a weird security model.

This means that all drivers written for the Android hardware platform cannot be integrated into the main kernel tree, And they will fail to be compiled in the main kernel. Because the code they depend on only exists in Google's kernel branch. Because of the above, Google hinders the integration of a large number of hardware drivers, platform code, and the main kernel tree. And created a kernel branch that many manufacturers currently rely on. (Comments from the Translator: evil practices, making use of open-source results for profit, but not giving back to the open-source community)

There is no problem in creating the kernel source code branch. Almost every release has its own branch. But worse, Google does not integrate their code into the main kernel tree, making it impossible for companies that write drivers and platform code to return to the open-source community. The kernel development community told these companies a few years ago to merge their code into the main kernel for automatic security fixes and API changes. Many companies follow the advice, each release of the kernel contains a large amount of code contributed by these companies.

But now they are stuck, and Android-related platform code and drivers cannot be integrated into upstream systems, which forces these companies to significantly extend their maintenance and development cycles.

What should I do?

I really don't know. Google did not show any signs of integrating their code into upstream games. Some companies want to modify Android-related interfaces to integrate upstream games, but this requires a lot of effort, which is not necessary.

Hope

I still have hope that Google will spend time modifying their code libraries, integrating them into upstream code, and stopping their huge obstacles to a large number of Embedded Linux hardware companies.

In the past, I proposed to help complete this work in private. Now I am making a public statement again, but I need the help of Google developers. Without them, nothing can be changed. The good news is that all modifications to the kernel/user's empty room APIs have no impact on all the code (such as applications) on the upper layer of the android stack, therefore, these tasks can be completed without affecting the overall situation.

I will discuss this issue again on the "2010linux consumption e-forum" (Ce Linux Forum 2010 Conference. I hope they can improve this issue before the meeting, otherwise the Forum will follow a long tradition and the speaker will complain loudly to the participants about the bad things they are doing.

 

From: http://www.ifanr.com/6876