Feeds

Google's Android code deleted from Linux kernel

'Go fork yourself!'

The essential guide to IT transformation

After removing Google's Android driver code from the Linux kernel, Novell Fellow and Linux developer Greg Kroah-Hartman has argued that the mobile OS is incompatible with the project's main tree.

Kroah-Hartman deleted the Android drivers on December 11 - Android code is no more as of version 2.6.33 of the kernel release - and yesterday, with a post to his personal blog, he explained the move in detail.

"No one cared about the code, so it was removed," writes Kroah-Hartman. "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 the larger problem, he continues, is that Android uses a new lock type, new hooks for its "sometimes bizarre" security model, and a revamped framebuffer driver infrastructure. All this, he says, prevents "a large chunk" of Android drivers and platform code from merging into the main kernel tree.

Google, he ultimately argues, has forked its mobile OS.

Google did not immediately respond to our request for comment. But in a pair of posts to LWN.net, Mountain View open source guru Chris DiBona says that Android isn't in the main tree because the main tree doesn't want it.

"I think if the Android kernel were important enough to the mainline, then this wouldn't be a problem. The reality is that the mainline doesn't want the code, so a fork is a normal response to this," DiBona writes.

"This whole thing stinks of people not liking Forking. Forking is important and not a bad thing at all. From my perspective, forking is why the Linux kernel is as good as it is."

From where Kroah-Hartman is sitting, Google has built a platform that's incompatible with the Linux kernel. "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," he writes.

"[Google is] effectively creating a kernel branch that a number of different vendors are now relying on."

And, he continues, this fork is "much worse" than the typical fork. "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," he says.

"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."

According to Kroah-Hartman, Google "shows no sign of working to get their code upstream anymore," and he says that the company's cooperation is essential. "A number of [necessary] 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," he says.

DiBona bears this out. But he believes the fork is nothing but a good thing. "If you don't like how we architected android, don't complain that the code isn't being mainlined," he says. "You can't have your cake and eat it too. We get it: you don't like how we put together the kernel for android. We're okay with that. Other companies coming to you for help is fine, too, you can choose who you help. Others might see that as an opportunity, but whatever." ®

5 things you didn’t know about cloud backup

More from The Register

next story
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Mozilla's 'Tiles' ads debut in new Firefox nightlies
You can try turning them off and on again
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
Scratched PC-dispatch patch patched, hatched in batch rematch
Windows security update fixed after triggering blue screens (and screams) of death
This is how I set about making a fortune with my own startup
Would you leave your well-paid job to chase your dream?
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Advanced data protection for your virtualized environments
Find a natural fit for optimizing protection for the often resource-constrained data protection process found in virtual environments.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.