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

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

John Stultz wrote (2012-10-11):

What is left here is the driver wakeup_source enablement to utilize the
upstream work. Currently the Android tree has a wakelock.h shim that
maps legacy wakelock usage to wakeup sources, but we need to migrate
that to direct wakeup_source usage and push those patches (in a number
of subsystems) upstream.

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.

I think the key item to get binder upstream would be to find non-Android
use cases, where there is community interest in solving a similar
problem, and so far that hasn't been very productive (kdbus was maybe
the closest, but I've not seen too much heavy lifting going on there).

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.

Apparently, some Samsung developers made progress getting most of the Android USB Gadget driver
upstream. There is an issue related to ccg and changing the sysfs interface to configfs.

ccg = configurable composite gadget. It was moved to staging/ccg in September 2012.
Apparently, this is related to the Android USB driver, which has multiple USB functions.

ccg is in staging and nobody is working on it. The configs interface requires
some cleanup of the current infrastructure to make it usuable with multiple
UDC, multiple functions etc. There are patches for of the configfs part from
Andrzej

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

Anton said (2012-10-11):

The work is ongoing, and now it's much more than 'low memory killer':
we're rethinking the whole userland-assisted memory management for Linux,
and this also slightly touches volatile ranges idea (but not code).

This new infrastructure will be suitable for Android (and it is developed
keeping Android needs in mind), but to get it into upstream we need to
make it generic and suitable for servers, desktops and 'other' embedded
use cases: memory-management folks are very intolerant to any ad-hoc
solutions. There's a lot of design work and discussions are still going on
in LKML, on meetings and privately.

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 ; new system pstore RAM backend is mainlined

waiting for use by Google in Android

no

Anton Vorontsov

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)

In October 2012, Anton said:

I worked on this item. Everything is in mainline now. It is no longer just
'ramconsole', it is now called "pstore filesystem" and "pstore RAM
backend", placed under fs/pstore/. It can do console, panic and trace
recording.

As far as I know, Google team plans look at it/validate next year.

Some Intel and Google folks and I are jointly maintain the code, the GIT
tree of the project is following:

The idea of FIQ debugger is accepted by the community, and as of this
merge window, the core support merged into the mainline kernel. ARM
specific and "restricted KDB command set" patches are still under review,
the plan is to get them into the next kernel release.

As it usually happens during upstreaming process, the small "FIQ glue"
project ended up being a generic facility, so this is now called "NMI
KGDB/KDB debugger", not just ARM FIQ glue code.

The generic driver is now drivers/tty/serial/kgdb_nmi.c.

Further development (i.e. ARM-specific bits, and restricted mode) is going
on in the following GIT tree:

USB

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 mainline Linux kernel will shrink.

Note: This table is not up-to-date and is hard to measure anyway. The inclusion of a lot of material into 3.3 obsoletes the need for a per-patch tracking mechanism (maybe?). Also, there will always be some difference, due to board support packages and new development areas (like ion), so the goal is not really 0 differences, but just a reduction overall. I'm not sure if we'll maintain this table or not, but I'm leaving it for now as a placeholder.