android-3.4 ... / Audit of OOT android code
john.stultz at linaro.org
Tue Jun 12 00:09:45 UTC 2012
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
> 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:
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:
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.
More information about the linaro-dev