In two reports filed from this week's OSCON conference, The Register says that Google will open Android's internal development kit to contributors, and that Linux maintainers are holding tough in negotiating with the search giant regarding Android's readmission to the kernel. Meanwhile, Linux 2.6.35 RC6 was released, featuring enhancements to network scalability, memory management, and sleep-wait detection.

In an article posted from the O'Reilly Open Source Convention (OSCON) conference being held in Portland, Oregon, this week, The Register's Gavin Clarke reports that Google will open up its Android development process to accept more outside contributions.

Citing comments expressed at OSCON by Android open source and compatibility program manager Dan Morrill, Clarke writes that at some undisclosed date, Google will change Android's Native code Development Kit (NDK) so that "contributed code joins the publicly available Android source tree rather than going into Google's private tree."

Morrill subsequently explained that Google wants contributions from the community because "they add value," Clarke added. Google is looking on a project-by-project basis at what code contributions it wants to make open, according to the story.

"There's no reason not to be in the open," Morrill was quoted as saying.

The Android NDK is a companion tool to the Android SDK (software development kit), and is designed to "build performance-critical portions" of apps in native code, according to the Android project. In addition, Google recently released an App Builder GUI programming environment for less technical users who want to develop Android apps.

Pre-release code to remain closed

On the other hand, public contributions won't be possible on unreleased versions of Android, writes Clarke. Google plans to continue to keep new versions of its mobile OS closed until launch for competitive reasons, says the story.

"We do have specific reasons for why some things we do we keep internal, because we compete with other companies in the electronics space," Morrill was quoted as saying.

Google not only wants to retain competitive advantage, but also wants to maintain some quality control over the Android platform, suggest Clarke. At one point, Google was forced to persuade an unnamed OEM that wanted to start shipping a prerelease version of Android 1.5 to hold its fire, Morrill was said to have told OSCON attendees. Apparently, the company tightened its development process after this incident.

"We realize we struck a balance a lot people in the free software community might not think is ideal, but we think it works for us," Morrill was said to have told the audience.

Meanwhile, Google now claims that submission rates on Android 2.2 have been 150 per cent higher than with Android 2.1, says the story. Some 40 companies are said to be official Android contributors, with 1,000 contributions having been made to date.

Morrill was also said to have noted that Google is trying to convince mobile system-on-chip manufacturers like Qualcomm and Texas Instruments to open up their code to work with Android features such as the radio interface link hardware abstraction layer.

Linux maintainers offer path for Android's return to the kernel

In a separate story posted from OSCON, The Register's Clarke interviewed Linux kernel SCSI subsystem maintainer and Novell distinguished engineer James Bottomley (pictured) about how Android might be rejoined with the main Linux kernel tree. 

In February, Novell Fellow and kernel developer Greg Kroah-Hartman announced that he had removed Google's Android driver code from the open source Linux kernel (kernel 2.6.33) on Dec. 11. The code was said to have been excised because the Linux-based Android platform has become incompatible with the project's main tree, due in part to Android's "sometimes bizarre" security model, but mostly due to lack of effort by Google, Kroah-Hartman wrote at the time.

"No one cared about the code, so it was removed," Kroah-Hartman added.

Now, Linux kernel maintainers have offered Google three ways to return Android into the good graces of the Linux kernel, Bottomley reportedly told Clarke. In order to get Android code reinstated to the kernel, Google may choose between the following options, said Bottomley:

• Put the stubs of Android's wait locks into the main kernel.
• Introduce Android's wait locks as PMQOS constraints.
• Adopt a patch written by a Linux kernel maintainer that would re-implement wait locks in a "socially acceptable way,"

"We need their feedback on the three options," Bottomley was quoted as saying.

Google has said that it has offered Android code for inclusion in the Linux 2.6.34 kernel, writes Clarke, but these failed to materialize.  Meanwhile, The Register quoted Google open source programs manager Chris DiBona (pictured), who gave one of the OSCON keynotes this week, as saying that he doubts the code will be included in the next version of the kernel.

"We are still talking to them [kernel maintainers] — we'll see what happens," DiBona was quoted as saying. "We want to be in there. It will open up a lot of devices to the kernel."

The impasse now appears to be based on the Linux maintainers' denial of Google's proposal to hack the kernel's PMQOS sub-system "to facilitate changes designed for mobile devices," writes Clarke.

Google proposed "a set of suspend locks - actions that intervened in the race around the phone's system during shut down process in response to an incoming call," he added. "The suspend locks were designed to stop shut down so that the user doesn't miss their call."

Bottomley told The Register that despite the Google proposal's "very elegant" sleep and suspend routine, it also introduced unwanted "wait locks to get around the race problem."

According to Bottomley, of the three paths to inclusion offered by his fellow kernel maintainers, the "stubs" approach has the least to offer since it's a temporary technique used to simulate functionality on different platforms, and would be removed after nine months if no permanent solution was developed, says the story. Instead, Bottomley would favor implementing wait locks as PMQOS constraints, or better yet as the more "socially acceptable" full patch options.

Yet the decision, Bottomley suggests, lies with Google and the Android community, not, as DiBona seems to suggest, with the Linux kernel community. Meanwhile, Google continues to be a regular contributor to the Linux kernel outside of the Android realm, for example contributing network scalability code the Linux 2.6.35 (see below).

Looking to Linux 2.6.35: Network scalability and memory management

The Linux Foundation released its latest "Linux Weather Forecast," offering a preview of Linux 2.6.35, which should be ready in early August, according to the report's "chief meteorologist" Jonathan Corbet (left) he 2.6.35 kernel was released yesterday (see link farther below), and "might" be the last prepatch before the official 2.6.35 release.

 With the merge window now closed for the release,"we can talk with confidence about the features that will be included," in Linux 2.6.35, which Corbet allows, offers "a relatively unexciting development cycle with regard to new features."

Still, the release offers improvements to network scalability, memory management, power management (sleep-state detection), and Btrfs file-system I/O capabilities. In addition, with over 8,000 changes having been implemented into the mainline during the merge window, there is "a lot of internal cleanup and improvement," he adds.

Key features are said to include:

• High-end network scalability should be improved with new receive packet steering and receive flow steering mechanisms added to the networking subsystem, thanks to contributions from Google.
• The memory compaction patch set has been merged, offering the potential for less memory fragmentation and higher success rates for large allocations while improving memory management performance.
• The cpuidle "menu" governor now features idle pattern detection "which tries to be smarter about sleep-state selection based on recent system history."
• The Btrfs file-system now has basic direct I/O support.

The Linux Weather Report also sums up the highlights of the recent Linux 2.6.34 release. The latest kernel featured new "Ceph: and "LogFS" file-systems and asynchronous suspend and resume, among other features.

Availability

The Register's story on Google opening up its Android NDK may be found here, and its story on the negotiations with Google over inclusion of Android code in the Linux kernel should be here.

The Linux Foundation's Linux Weather Report should be here.

---

This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.