android-3.4 ... / Audit of OOT android code

[John Stultz]

On 06/10/2012 02:53 AM, Andy Green wrote:
> On 05/24/2012 11:06 PM, the mail apparently from Andy Green included:
>
>> Putting it another way if Linaro isn't going to take even a modest
>> amount of care about the OOT Android content making problems in vanilla
>> case, we probably aren't ready to add this lot to a vanilla basis.
>> Irritating as that is for me as much as anyone.
>
> Here is an audit I did myself today of OOT Android content needed to 
> understand what we're adding to Linaro kernels for vanilla case.  It's 
> looking at the changes from POV of someone who does not want the 
> additional Android content to build into their kernel or affect 
> actions when deconfigured.
>
> Things are "harmless" if they don't unconditionally change the source, 
> the CONFIG_ they depend on is not "default y", or by looking at the 
> code I determined that it's reasonable or even beneficial.
>
> These are the suspicious things I found from the diff between 
> linaro-android-3.4 (from 
> http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-android-3.4 
> at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4.  Some are 
> clear cut and others change code I don't really understand, but others 
> on this list will.
>

Interesting log, I appreciate the effort you took here.   I don't really 
have too much to add here, but I'll comment on the few items below I 
have a bit of context on.

>      1) drivers/input/evdev.c: adds wakelock code not dependent on 
> ANDROID *** need discussion ***

I *believe* the evdev/wakelock changes has landed in modified form 
upstream in 3.5 as:
     4d7e30d98939a0340022ccd49325a3d70f7e0238
     epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll 
events are re

Although for now I'm still carrying the evdev wakelock change in my 
3.5-jstultz-rebase tree (since Android userland will need to be updated 
to use EPOLLWAKEUP).

>     22) arch/arm/kernel/etm.c: mass changes, no idea *** needs 
> discussion ***
>
I've pinged the etm driver maintainer on the status of these patches as 
part of this blueprint:
     
https://blueprints.launchpad.net/linux-linaro/+spec/android-etm-upstreaming

And as you noticed we have some fixes pending in the linaro-android-3.4 
branch that I plan to send those up to AOSP when I get a chance.  Feel 
free to send me other changes and I'll queue them as well.

thanks
-john