On 24/05/12 06:42, Somebody in the thread at some point said:
On Wed, May 23, 2012 at 02:21:50PM +0800, Andy Green wrote:
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.
Generally when analyzing a situation like this I think the first question is whether feature X will be merged upstream, and then the question is whether it would be protected by CONFIG_ANDROID.
How does the interactive governor fair against this criteria? Will it be accepted upstream, and if so, will it be behind CONFIG_ANDROID=y?
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.
Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable?
(If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.)
Pretty much, I think they're saying to their customers, "here's an enabled vanilla tree" and then nobody wants to see problems coming from OOT Androidization series. Since we already had "funny things" in vanilla build from the series, this isn't so paranoid to be concerned about.
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.
I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined?
Someone needs to audit the OOT Androidization stuff and confirm that for patches that go "out of their box", ie, reach out of /staging or some specific driver:
- the impact of the patch is negated if CONFIG_ANDROID or some more specific config is disabled, or,
- remove the patch as too invasive, or,
- conclude the patch is useful and needed in vanilla case too
there's a big variety of "out of the box" patches for stuff like cache code, mmc core, network stack and so on in that series last time I looked. We should give some assurance for people using linux-linaro-core-tracking that someone at least looked at each of those cases and determined its status as above.
-Andy