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)
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
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
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.
to post comments)