Feeds

Google's Android code deleted from Linux kernel

'Go fork yourself!'

Security for virtualized datacentres

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

Internet Security Threat Report 2014

More from The Register

next story
PEAK APPLE: iOS 8 is least popular Cupertino mobile OS in all of HUMAN HISTORY
'Nerd release' finally staggers past 50 per cent adoption
Microsoft to bake Skype into IE, without plugins
Redmond thinks the Object Real-Time Communications API for WebRTC is ready to roll
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
Mozilla: Spidermonkey ATE Apple's JavaScriptCore, THRASHED Google V8
Moz man claims the win on rivals' own benchmarks
FTDI yanks chip-bricking driver from Windows Update, vows to fight on
Next driver to battle fake chips with 'non-invasive' methods
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Ubuntu 14.10 tries pulling a Steve Ballmer on cloudy offerings
Oi, Windows, centOS and openSUSE – behave, we're all friends here
Was ist das? Eine neue Suse Linux Enterprise? Ausgezeichnet!
Version 12 first major-number Suse release since 2009
prev story

Whitepapers

Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
New hybrid storage solutions
Tackling data challenges through emerging hybrid storage solutions that enable optimum database performance whilst managing costs and increasingly large data stores.
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.