On Tue, May 22, 2012 at 1:21 AM, Andy Green <andy.gr...@linaro.org> 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 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. > > 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.
It makes sense, and I also agree that we should only have Androidization related patches at core if they can be properly switched off by a config. This is probably a requirement for upstream anyway, so I don't see as an issue on our side. The rest of the patches could be part of linux-linaro, like we have for the other LTs. That would help already identifying what are the remaining issues for an unified tree and also getting the enablement for all the LTs that are part of linux-linaro. Here the core-tracking branch should be used just for common and stuff that has a good change of hitting upstream. If you still need more clean-up work, then merging it at linux-linaro would be the way to go. Cheers, -- Ricardo Salveti de Araujo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
