Android core platform meta-blueprint

All features under this blueprint have since been merged into staging or upstream.

A number of the items in staging have work pending to upstream them for good:
  * Ashmem
  * low-memory killer
  * Logger

A number of these items have been merged upstream.
  * evdev
  * wakelocks
  * alarmtimer

Work not covered:
  * Binder - In staging, but its one of the nastier bits to try to upstream "properly". Hoping it can be merged as-is as a compatability layer (similar to sysV ipc).

New items recently added are compat ioctl support for Binder and Ashmem drivers.

Historic info from earlier UDS:
4 items that are next steps:
- Wake Locks
- Ashmem
- Logger
- OOM Killer aka lowmem killer
Arnd: What he wants to understand before details. Android tree has lots and lots of patches. Are the above ones all that is needed for user space.
John: Ashmem, binder, and logger are all that is needed to boot the Android user space
You can run an Android user space w/o wake locks, you just won't get it suspend.
Recent News from KSummit:
Paul M: Linus T. that stuff is not perfect, but we have millions of users. Alan Cox thought it was error to not include it. Dave Airlie was not completely convinced, and so are several other people in the kernel community.
Since there are so many users, the wake locks ABI is really important.
Arnd: All the above are currently char devices. Can that be changed to use sysfs, netlink, etc and change the libraries that the applications use to acess them? Zach: The only guarantee given to app developers is the library interface.
Arnd: The fact that there are millions of users proves that there is a need for a specific functionality in the kernel, but not that there is a need for a specific interface into the kernel.
Logger: Never actually been fully submitted. Was in staging tree at one point but then pulled out. CEWG (Tim Bird) at LF is planning on looking at this.
Brian Swetlands explanation of logger:
http://lwn.net/Articles/464362/
There was a discussion about logging at KSummit. Alan Cox mentioned that kernel already has certain interfaces (netlink) for transferring this type of data to the kernel, but there was not overal consensus on this.
Arnd: Netlink is probably a good interface for kernel -> userspace messages (i.e, possible printk replacement) but not for the management of user-space generated messages.
Logger stores messages in a known location so that in case of panic, we can grab the message on safe reboot.
Arnd, Nicolas: The logger work could tie in with the System Trace Macrocell
       Linus: ETB: embedded trace buffer - nokia was using this, hitting sysrq key displays the buffer in the console (arch/arm/kernel/etm.c)
STM is not an all ARM devices, but we could have a shared API.
Zach: Use fixed location via device tree to give a pstore like backend
Deepak: Could provide per-device information so in DT so that we have a single mechanism to manage log-buffers for remote devices and on-CPU generated logs.
LOWMEM Killer:
Android apps are written with the assumption that they can always be killed. A signal is
sent when an app is about to be killed so it can save state.
ACTION: Need to get better sense of the Lowmem and Logger APIs this cycle
Zach: Need a unified RPC messaging mechanism.
Deepak: Community is moving to rpmsg.
Linus W: I would love for Android/Brian Swetland to push for the rpmsg if they like it, because SoC vendors listen to Android and do what they say