ABS: Android and the kernel mainline

On the first day of this year's Android Builders Summit, a panel was held to discuss the Android patches to the Linux kernel, including the progress on getting them upstream. The panel consisted of Zach Pfeffer from Linaro, Tim Bird from Sony, Arnd Bergmann of IBM/Linaro, and Greg Kroah-Hartman of the Linux Foundation (LF), with LWN executive editor Jonathan Corbet moderating. The overall feeling from the panel was that things with the Android kernel patches were proceeding apace—recent kernels can boot into an Android user space—but there is still work to be done. While I could not attend ABS this year, this report comes via the magic of streaming video.

Each of the panelists introduced themselves and connected themselves to Android in various ways. Pfeffer is the Android platform lead for Linaro and is responsible for creating Android builds for each of the member companies, Bird represents Sony as the architecture chair of the LF Consumer Electronics working group, Bergmann has recently been working on the cleanup and consolidation of the ARM subtree, and Kroah-Hartman maintains the staging tree where most of the Android code currently lives.

Corbet kicked off the discussion by noting that he had recently looked at the current Red Hat Enterprise Linux (RHEL) kernel, which includes more than 7600 patches on top of the mainline kernel. He also pointed out that the Fedora kernel carries a number of different patches that aren't likely to go upstream anytime soon (utrace, in particular). Given that, "why are we here?", why is Android (and its patches) treated differently than other distributions' kernels, he asked.

Kroah-Hartman said that the Android patches are only about 7000 lines of code and that some UART drivers are larger. But people care more about the Android patches because device makers and others have to pull down all those patches and apply them to get a mainline kernel working with Android. It is different from enterprise kernels, he said, because there are no real downstream users of the source code of those. Bergmann also pointed out that much of the change in the RHEL or Fedora kernels was for things like drivers which don't change the operating system core as some of the Android patches do.

Pfeffer noted that in the past the kernel developers were seen as "the rebel alliance", but that now the Android developers have assumed that role to some extent. Bird pointed out that part of the problem is that due to the success of Android, the kernels for board support packages (BSPs) are being built with Android kernels, rather than kernel.org kernels. That essentially causes a split in the community.

The Android patches are largely in the mainline at this point (in staging), Kroah-Hartman said, except for the wakelocks code. The 3.3-rc3 kernel can boot an Android user space, but lacks the power management features that wakelocks provide, so battery life is poor. Bergmann said that he had seen a demo of Android running on a mainline kernel, and there is "still a long way to go".

One area that needs attention, Bergmann said, is the user-space interfaces of some of the Android features. Those may not be what the kernel developers want to support long-term, so they need to be addressed before the Android patches make their way out of staging and those interfaces become part of the kernel ABI.

The PMEM patches, which provide a means to reserve contiguous memory and to share buffers between the kernel and user space, was the next topic. Corbet noted that PMEM had been in and out of staging twice, but had never been merged. Since then, Android has moved on and is not using PMEM any longer. So, was it the right move not to merge PMEM, he asked.

The panel seemed in agreement that it was right not to merge those patches, with Pfeffer noting that they were simply an expedient to get products out the door. As ARM matures, he said, common usage models will come about, rather than various quick fixes. Kroah-Hartman pointed out that the memory management kernel developers told the PMEM developers "how to do it right", but that no one ever did that work, which is "a problem that we've had forever". Bird agreed with Pfeffer, saying that he is pushing to get things into the mainline, but that if there is pushback, "that's fine", as there are sometimes "quick and dirty" things done to ship products.

Corbet pursued that topic with a mention of the contiguous memory allocator (CMA) that is being pushed by Samsung and is aimed at Android. But he noted that Android itself has moved from PMEM to the ION memory allocator, which duplicates some of the CMA functionality while adding another user-space interface. What should be done about ION, he asked.

Android is not "pushing" ION, Pfeffer said, and if the kernel community doesn't want it, it shouldn't take it. There was a need for a solution that didn't exist in the mainline, so Android went ahead with ION. It may not necessarily be easy to work with all of the Android kernel patches, he said, because of the time pressures it is operating under. In the end, ION could be handled much like PMEM was, he said.

But Bergmann pointed out that ION could be integrated with CMA and the DMA buffer sharing work that are getting close to the mainline. ION and the soon-to-exist mainline solutions are not mutually exclusive, he said. Pfeffer said that the "entire room" doesn't really care which solution is chosen, they just want something that has been integrated and tested. That may be ION now, and something else down the road.

In a sense, this is a result of the longstanding conflict between the needs of the embedded world vs. those of the rest of kernel, Corbet posited. But Kroah-Hartman disagreed, saying that the enterprise distributions have the same problems, just on a different timescale. Those distributions need to ship, often well before the code is upstream. Embedded isn't really different, they just need to get their code upstream as well, he said.

One place where it is different, though, is that in the embedded world things may move from hardware to software at a relatively rapid pace, Pfeffer said. That means that a driver written for hardware JPEG decoding may really only be needed for one six-month product cycle, so that driver really doesn't need to go upstream. Because of that, Bergmann said, many of those drivers are designed to stay out of the mainline. Bird echoed that, saying that sometimes a "fatalistic approach" to kernel development is the pragmatic choice. Even for long-lived code, if there is no hope that it can go upstream, developers will just try to focus on making it maintainable out of tree.

For a long time, the trajectory of Android code was heading away from the mainline, Pfeffer said, but that has started to correct itself. Though the kernel needs more maintainers so that code can get upstream faster, he said. Bergmann agreed that more maintainers would help, but the work needs to be done in a more organized fashion with an eye toward getting the user-space interfaces right.

Bird said that he doesn't expect there to be a need for another panel of this sort because the problem is solving itself at this point. Kroah-Hartman more or less agreed, noting that the Android problems are "nothing new" and that the kernel community has been solving these kinds of problems for 20 years.

With luck, the Android developers won't be adding much more to the core, Corbet said, but what about drivers? CyanogenMod is trying to get Ice Cream Sandwich (Android 4.0) in the hands of its users, but is running into problems with getting drivers from some vendors. What can be done to solve that problem?

Kroah-Hartman noted that things are getting better in that department, but that some companies care about getting their drivers into the mainline, while others don't. The latter don't realize that it will save them money in the long run. He is often talking with various companies, so if there are specific instances of problem drivers, he wants to know about them.

But kernel drivers are not the whole problem, Pfeffer said. In the graphics and video realms, the line between the kernel and user space has been "blown away", he said. There is now firmware, kernel interfaces, binary blobs, and user-space interfaces to do graphics which are all released in lockstep, and often all as binary blobs, which is not a good thing. It isn't an engineering issue, but a legal one, he said. Google's engineers do not want binary blobs, he said, and have been pushing back on vendors for things like the Nexus line of phones.

Bergmann also pointed to the open source driver for the Mali GPU as an indicator of the direction where things are headed. If the other graphics vendors don't get their act together with respect to free drivers, they will not survive, he said.

With that, the 45-minute slot had expired. The upshot seems to be that mainline kernel support for Android is moving along reasonably well. It won't be too long before it will be possible to run Android on a mainline kernel while still maintaining some reasonable battery life. Beyond that, though, the process is working more or less as it should. The out-of-tree Android patches were just another in a long line of hurdles that the kernel community has overcome.