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
--
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
