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