On 05/17/2012 09:00 PM, Andy Green wrote:
On 18/05/12 09:49, Somebody in the thread at some point said:
Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team has
released a -compat tree for their 3.4 kernel. Basically this tree
re-adds some items like earlysuspend and classic wakelocks in order to
provide better compatibility with old (and by old, I really mean current
as far as we see - so ICS and earlier) Android userland.
Since we're still shipping ICS, and have no access to whatever the
Android 5.0 userland will be, it seems merging in the -compat tree would
make sense.
However, I know Tixy and others have already tried to address the lack
of earlysuspend in the android-3.3+ kernels, so I wanted to double check
that this wouldn't cause additional pain (since those adjustments might
need to be reverted).
So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold off till
this months release is done, so we don't risk any last minute gotchas).
The only worry I can see is that now even vanilla versions of LT
kernels are basing off llct that includes Androidizaton, even vanilla
will have possibly invasive wakelock code.
Could you expand a bit more on your concern here? Is the the wakelock
infrastructure you're concerned about, or the driver changes made by the
wakelock usage? Or is it just other nebulous changes in the Android tree?
It might be good to briefly audit the changes to confirm they don't
appear if CONFIG_ANDROID is off. Google might not take much care
about that case but I think it might be important for us.
So while wakelocks should turn into a noop if they are disabled, there
are other changes in the Android tree that aren't necessarily config
switched. However, since we are trying to push these patches upstream,
I think its actually good that we test these changes in non-android
settings, since its the hope that they will be there eventually, if not
soon.
Of course, if there are specific issues that pop up, we can either work
with Google to add needed switches so the code can coexist, or rework
the changes so the feature is runtime selectable.
thanks
-john
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
