Android Mainlining Project

From eLinux.org
Revision as of 15:28, 4 January 2012 by Bhairavi (talk | contribs) (Patch/Feature Status Chart)
Jump to: navigation, search

This page is for organizing the Android Mainlining Project. It has information and resources associated with this project.

Goal

The goal of this project is to ultimately mainline all patches required to run the current released version of Android. The purpose of mainlining these patches is 3-fold:

  1. to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
  2. to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
  3. to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers

To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.

Process

[This is a draft section, up for discussion]

Overall:

  • identify all patches/features, and categorize into core or non/core
    • core = feature is required or strongly desired for Android operation on a platform
    • non-core = Most of the Android system can run without the feature

Per feature or patch:

  • research any previous submission feedback
  • incorporate feedback, as appropriate
  • negotiate any interface changes with Google Android team
  • submit updated patches to mainline
  • repeat until accepted

Resources

People

People who have expressed interest in this:

  • Tim Bird
  • John Stultz
  • Paul McKenney
  • Deepak Saxena
  • Arnd Bergmann
  • Thomas Gleixner
  • Arjan Van de Ven
  • Brian Swetland
  • Tetsuyuki Kobayashi
  • Andy Green
  • Victor M. Jaquez
  • Jesse Barker
  • Anton Vorontsov
  • Greg Kroah-Hartman
  • Shuah Khan

roles/expertise

This section has miscellaneous notes on roles, capabilities and expertise of group's members

John Stultz is the owner of the Linaro blueprint for mainlining Android features. Tim Bird is the owner of the CE Workgroup project for mainlining Android features. Deepak and Jesse can help make arrangements for a meeting at Linaro Connect. Tim can help make arrangements for a meeting at Android Builders Summit.

  • John Stultz has worked on POSIX Alarm timers
  • Jesse is working on shared memory buffers related to pmem/CMA/parts of ion
  • Anton Vorontsov is looking at the lowmemory killer
  • Greg has put some Android patches into mainline (under drivers/staging/android) previously
    • Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011
  • Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)

Plans

  • Set up mailing list - Tim is working on it - probable name: ce-android-mainline@list.linuxfoundation.org
  • Set up meeting at Linaro Connect or ABS - Tim (with Deepak and/or Jesse's help)
  • Update this page with latest info (for December 2011) - Tim
  • Make a general announcement of the project to celinux-dev and linux-embedded - Tim

Patch/Feature Status Chart

Feature/Patch Description Status Part of core? Owner/Interested parties Notes
logger kernel support for Android system logging not mainlined (but see linux-next staging as of 12/19/11) yes Tim Bird should be non-controversial (though I'm always surprised)

See Mainline Android logger project for a list of ideas, issues and a project plan for this feature Also see this LKML discussion thread

wakelocks Power management locking mechanism to prevent opportunistic suspend not mainlined yes Rafael Wysocki Is important due to impact on board support and drivers by 3rd parties
Android alarm timers Timers that count down during suspended operation, and can wake from suspend Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/ yes John Stultz Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.
ashmem Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure not mainlined yes John Stultz Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed(no tmpfs mounts, atomic create/unlink behavior,etc).
network security special permission checks for secure access to network operations not mainlined ? (can run without it, but network security won't be enforced) no one May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
binder Android inter-process communication mechanism not mainlined (but see linux-next staging as of 12/19/11) yes no one Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining
Android pmem driver manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.) not mainlined yes Shuah Khan Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need?
Android USB gadget driver
wireless features (more specific please?)
timed gpio perform gpio operations as a result of specified timeouts not mainlined (but see linux-next staging as of 12/16/11)
low memory killer feature to manage application lifecycle in low memory conditions not mainlined (but see linux-next staging as of 12/16/11) yes (but system might work without it) Anton Vorontsov See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches
ram console ability to save console output to a reserved ram area for diagnostics on a subsequent boot not mainlined (but see linux-next staging as of 12/16/11) no Shuah Khan No lkml submission history found so far.
timed output
ion graphics memory driver graphics memory drivers thingie not mainlined yes (for 4.0 and later?) Jesse Barker

Progress Chart

This section is intended to show our progress, by showing the patch set size over time. With any luck, as we get features into mainline, the difference between the Android kernel and the legacy Linux kernel will shrink.

  • diff of 2.6.29 kernel.org tree versus kernel
Kernel Version Files changed insertions deletions hunks bytes in diff
2.6.29 187 123506 0 187 3291827