On 22/05/12 23:57, Somebody in the thread at some point said:
On 05/21/2012 09:21 PM, Andy Green wrote:
On 22/05/12 01:58, Somebody in the thread at some point said:
On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:
like Andy, I am a bit concerned that we merge the android stuff
into the linaro-core and that we get android candies in 'vanilla'
kernel. can't we (shouldn't we) have -android on top of -core and
pull -android only into 'android' kernel? it's true that for most
things, -android is not impacting a 'vanilla' kernel, but clearly
>from the outside (community *and* customers) a kernel 'tainted'
with Android is not a 'vanilla' kernel anymore...
So this re-opens the discussion we've been having since at least
last Oct in moving to a consolidated kernel.
Since Android upstreaming is an very active goal of Linaro, I think
there's strong technical value in putting the Android patches in
along with all the other Linaro trees, as it allows us to work out
any sort of incompatibilities or issues, so we can resolve them
prior to being pushed upstream.
I'm quite +1 on what John is saying. There was a time when there was
great uncertainty about the future of the Android patches, but since
Linus' comment last year it's become dead certain that the functionality
/will/ be merged upstream. We can pave the way by getting any
integration issues sorted out early -- similarly to what we do for
practically everything else in linux-linaro.
Hm I just said we should audit it for being dependent on CONFIG_ANDROID.
If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not
having Androidization patched in, people will stop wanting to get rid
of the patches. But since Google's interest is in the case it is
configured, I doubt they took care about having it disabled well.
For new or optional functionality, this is usually the case, but not for
all changes.
Having multiple config based code paths has additional maintainance
burden, so frequently if a change really should be generic there isn't
any need for a config. The simplest example of this are bug fixes, which
shouldn't be configurable off :)
For an example we had a problem yesterday with the Androidization
"interactive" cpufreq governor turning up unexpectedly in an Ubuntu
build and spamming block task logs. I dunno why it appeared yet, maybe
it's marked up as defauly=y or some config fumble on part of guy who
built the kernel.
For other configurable features in the mainline kernel, part of the
deal of getting in there is that they can be turned off nicely.
There's even a wholesale CONFIG_PM. But the remaining (200 or so last
time I looked) Androidization patches haven't been through that kind
of scrutiny by anyone. Again last time I looked they fiddled with a
fair amount of kernel guts, sometimes with additional config coverage
but not always.
Initially we added without discrimination that 7 year old patch that
turns dmesg into junk to llct because it came in with Google's
Androidization series. It suggests we're just shovelling them on
without any plan at the moment.
And I'd say in this case things worked ideally! Android tree had a very
old hack that has since become obsolete. You noticed it in the tree and
Yeah but that's what I am saying, we shovelled the patches on with no
plan about assessment or audit and just waited for trouble. It's fair
enough to do that on android-specific tree because it's for benefit of
Android guys. But some vanilla people don't want to participate in
finding bugs from non-mainline Android code they don't care about.
requested it be reverted. I've generated a patch to do so, and plan to
send it to AOSP in my next submission bundle. Once the Google guys
rebase, and squish the two patches down, we're down one more patch. This
is exactly the type of integration work I think we benefit from.
If this were something that we went in and just configured off, its less
likely anyone would notice it was unnecessary until we finished
upstreaming all the larger changes we're focusing on.
Some consumers of trees that are basing on linux-linaro-core-tracking
actively don't want the Androidization stuff and we need to make sure
their needs are met.
Similarly, Andrey and Tushar found early cases during the first few
integration attempts where parts of the Android patch set didn't align
with non-Android builds. They submitted patches that have since been
pushed back to AOSP.
With regard to your characterization of shovelling the patches in, its
true we've traditionally taken the patch tree in its entirety, in order
to produce Android builds that were fully functional. The positive news
is that as items have been making it upstream, we may soon be able to
reverse the model, only hand picking specific required changes from the
AOSP tree. This possibility has different pros and cons, so it may not
be the right approach, but its something I'll be looking at in the future.
If we're claiming we are converging these patches to upstream,
"working out integration issues" then we should be auditing them for
being properly dependent on CONFIG_ANDROID before adding them to the
same basis used for vanilla consumers.
So I'd welcome more help in reviewing and auditing the Android patch
tree with detailed care to accomplish what you're suggesting. That said,
I would suggest against blindly be adding #ifdef CONFIG_ANDROID all over
the code, as there are changes that shouldn't necessarily be
configurable. Working these out properly will take time and care.
Again, if there is a specific concern, please let me know and I'll try
to quickly address it, but I currently don't have the bandwith myself to
spend auditing the entire patch set with my current priorities. If that
is really unacceptable, we can have Andrey avoid merging the Android
tree into the linaro-core set, and instead merge it at a later phase.
But I think this would be unfortunate as we would miss out on wider
testing of the changes.
Personally I like the idea of the Androidization becoming part of the
basis because it puts us in generally converged direction with mainline.
But then we have a responsibility to make it as transparent as
mainline will insist that it is if we expect members are seriously going
to offer vanilla kernels on this basis.
If nobody's going to take care of that we should break Androidization
out again into a flavouring tree, annoying as that is to everyone
including me who was just getting used to offering one tree.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
