Feeds

Google's Android code deleted from Linux kernel

'Go fork yourself!'

Combat fraud and increase customer satisfaction

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

High performance access to file storage

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.