Difference between revisions of "Android Mainlining Project"

From eLinux.org
Jump to: navigation, search
(Patch/Feature Status Chart)
(Patch/Feature Status Chart)
Line 55: Line 55:
 
!Part of core?
 
!Part of core?
 
!Owner/Interested parties
 
!Owner/Interested parties
 +
|Notes
 
|-
 
|-
 
|logger
 
|logger
Line 61: Line 62:
 
|yes
 
|yes
 
|Tim Bird
 
|Tim Bird
 +
|should be non-controversial (though I'm always surprised)
 
|-
 
|-
 
|wakelocks
 
|wakelocks
Line 67: Line 69:
 
|yes
 
|yes
 
|Rafael Wysocki
 
|Rafael Wysocki
 +
|Is important due to impact on board support and drivers by 3rd parties
 
|-
 
|-
 
|Android alarm timers
 
|Android alarm timers
Line 77: Line 80:
 
|-
 
|-
 
|network security
 
|network security
 +
|special permission checks for secure access to network operations
 +
|not mainlined
 +
|no one
 +
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.
 
|-
 
|-
 
|binder
 
|binder
Line 83: Line 90:
 
|yes
 
|yes
 
|no one
 
|no one
 +
|Generated a fair amount of discussion on last submission. See
 
|-
 
|-
 
|pmem
 
|pmem

Revision as of 15:21, 12 December 2011

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 it 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


Patch/Feature Status Chart

Feature/Patch Description Status Part of core? Owner/Interested parties Notes
logger kernel support for Android system logging not mainlined yes Tim Bird should be non-controversial (though I'm always surprised)
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 Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/ yes John Stultz
ashmem
network security special permission checks for secure access to network operations not mainlined 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 yes no one Generated a fair amount of discussion on last submission. See
pmem
Android USB gadget
wireless features
timed gpio

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.