An interesting development happened during the release of the 2.6.33 linux kernel and generated some heated discussions on the lwn comments section. The android code in the linux kernel tree was deleted.
Why was it deleted? Greg Kroah-Hartman in his blog stated in a nutshell that:
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.
There was a more serious problem though, as stated by Greg:
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.
On the lwn comments section, Greg further stated that a number of hardware companies approached the kernel development community for help due to this problem.
Apparently part of the problem is the problem is that Google created a new kernel core infrastructure which in order for it to be placed into the mainline kernel, numerous changes in kernel and userspace have to be done. Google has essentially created a fork of the kernel.
Cris DiBona stated:
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.
The aforementioned fork was mostly in the implemention of wakelocks, a process of bringing a system out of various low power states.
Google found the current implementation inefficient, and due to time constraints and pressure to produce a product, made their own API implementation.
The downside of this is that in order for linux drivers new and current ones to work on Android, one has to hook up to the new wakelock mechanism. This causes lots of distress in maintaining current userspace and kernelspace development.
It was generally agreed that the problems of power management was an issue that needed to be solved. However, a number disagreed on the way that Google handled the solution, including the kernel developers.
The reason mainline hasn’t accepted the wakelock infrastructure is that Google has still failed to demonstrate why it’s necessary. Almost identical benefits can be obtained using the kernel’s existing range timer functonality, which has the added bonus of removing the need for the strong userspace/kernel tying that Android requires right now.
Interestingly enough, Nokia handled the problem more maturely than Google. Whereareas, Google basically sent a large number of patches and left it hanging, one user noted:
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.
It was further noted that:
But they both have to solve the same problems (power management) and the fact that Nokia seems to get good battery life out of their devices appears at first glance to be a counterpoint to the necessity of wakelocks.
The discussion went on, without resolution. Time will tell if the Android code will be resubmitted back to the kernel, and the issues that hamper it being in the mainline kernel tree will be resolved and taken care of.