Android versus Linux?
by Dj Walker-Morgan
Is Android at odds with Linux after the removal of Android device drivers from the Linux source code tree or is this business as usual for the Linux community and nothing new? The H looks at the issues.
Recently, Greg Kroah-Hartman announced that Google's device drivers for Android, had been removed from the Linux source code tree. To be exact, the drivers were removed from "staging", a section of the Linux source code tree for code which hasn't yet been adopted into the mainline of the Linux kernel code.
"Staging" is for code which isn't up to the code quality or integration that is expected for code being adopted by the Linux kernel. Staging serves as a central place for easier review, comments and fixes. Code in "staging" can be removed if it isn't being maintained, as Microsoft found when it submitted drivers for its Hyper-V virtualisation. Removal or the threat of removal, acts as a wake up call for the original developers. Once code has been adopted into the mainline, it is rarely removed even if the maintainer of the code vanishes.
But for Google, the problem goes far deeper than just maintaining the code; there are now elements of special code in the Android Linux kernel, and how it exposes itself to programs, which are not in the mainline Linux code. These differences would require some engineering to iron out, engineering which Google may not want to do as it is focussed on making Android competitive in the mobile phone market.
Google's Android development takes place behind closed doors, with the company's own Linux source tree. This isn't an uncommon model at Google; it runs its own source tree for its internally deployed Linux, allowing them to optimise for its specific uses for the operating system. LWN.net looked at the process in How Google uses Linux. Google's internal Linux is only now moving to version 2.6.26 of the kernel, having started with 2.4.18 and, after patching 2,000 files and inserting near half a million lines including back-porting 64 bit support, eventually moved to 2.6.11, and then 2.6.18, carrying patches forward where needed.
Each move, taking place around every 17 months, involves rebasing; the latest mainline kernel is taken and Google's coders then work to apply their patches and changes, where appropriate, to the new kernel. Google's developers understand that this is quite an engineering load, and are looking to get to a point where they are more in sync with the mainline kernel. But, some changes Google have made are contentious.
For example, 2.6.26 saw the CFS (completely fair scheduler) introduced to the mainline kernel, but CFS caused problems for Google's applications, built to run on systems handling 5,000 threads on 16-32 core systems. So they ported the old O(1) scheduler into their version of 2.6.26. Google is aiming to work with the community to implement changes which may bring them back in line with current Linux kernel development. At least Google rebase their code; back in the days of Linux 2.4, forks like this were not uncommon with Red Hat Enterprise Linux and SUSE Linux Enterprise server having their own versions of the kernel which were quite different from what was "upstream" in the mainline code. Both companies learnt the cost of the exercise and the benefits of working with the community and have subsequently moved to more closely following the mainline development.
For Google Android, similar challenges exist. The Android code is based on a Linux 2.6 kernel but Google's changes are widespread. For example, one of their changes is called "wakelocks", a mechanism implemented by Google's Android developers to handle power management. Wakelocks allow a program running on the platform to say "No, don't go into low-power state, I have things to do" to the kernel. This type of power management is important in mobile phones and other hand held devices, where battery life is of critical importance to developers and users.