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%3Ba=shortlog%3Bh=r... 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 onANDROID *** 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 *** needsdiscussion ***
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