Android Mainlining Project
This page is for organizing the Android Mainlining Project. It has information and resources associated with this project.
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:
- 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
- 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
- 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.
[This is a draft section, up for discussion]
- 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
- Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline
- Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming
- Meeting: Android mainlining interest group meeting 2012
- Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.
People who have expressed interest in this project are:
- 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
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)
- Update this site with information on latest patch status - ongoing, by anyone
- [FIXTHIS - add sections needing a status or status update]
Patch/Feature Status Chart
|Feature/Patch||Description||Status||Part of core?||Owner/Interested parties||Notes|
|logger||kernel support for Android system logging||in drivers/staging/android, in kernel version 3.3 2012.03.19||yes||Tim Bird||See Mainline Android logger project for a list of ideas, issues and a project plan for this feature
Also see this LKML discussion thread Some cleanup patches in linux-next, with some changes to avoid hardcoding logging channels (see Linus' tree commit: 10b241991fc) Tim was planning on doing channel allocation from user-space next, but Arnd may have talked him into doing a fs-based solution at LinuxCon Japan. (6/18/2012).
|wakelocks||Power management locking mechanism to prevent opportunistic suspend||parts mainlined, as of 2012.06.18, work in progress||yes||Rafael Wysocki||Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726. This code apparently made it into 3.4, with more code to appear in 3.5?
|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||in drivers/staging/android, in kernel version 3.3 2012.03.19||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||in drivers/staging/android, in kernel version 3.3 2012.03.19||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.)||Removed - no longer in use||yes||Shuah Khan||Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.|
|Android USB gadget driver||Support for Android as gadget device from host||unknown||? (not sure if needed for basic bringup or not, but would be really painful if missing)||no one?|
|timed gpio||perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.||in drivers/staging/android, in kernel version 3.3 2012.03.19||no? (is this needed for basic bringup?)||Shuah Khan||A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288|
|timed output||seems to just be a class for timed gpio items||in drivers/staging/android, in kernel version 3.3 2012.03.19||no? (required by timed_gpio)||Shuah Khan||A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288|
|low memory killer||feature to manage application lifecycle in low memory conditions||in drivers/staging/android, in kernel version 3.3 2012.03.19||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||in drivers/staging/android, in kernel version 3.3 2012.03.19||no||Shuah Khan||No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.
Anton Vortontsov moved some functionality from the ram_console into the new "persistent_ram" feature, in fs/pstore/ram_core.c (May 17, 2012 - see commit cddb8751c)
|ion graphics memory driver||graphics memory drivers thingie||not mainlined||yes (for 4.0 and later?)||Jesse Barker|
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 mainline Linux kernel will shrink.
- diff of 2.6.29 kernel.org tree versus kernel
|Kernel Version||Files changed||insertions||deletions||hunks||bytes in diff|