On Tue, Jun 7, 2011 at 5:33 AM, Dave Martin dave.martin@linaro.org wrote:
On Tue, Jun 07, 2011 at 11:31:51AM +0100, Andy Green wrote:
On 06/07/2011 10:58 AM, Somebody in the thread at some point said:
Hi -
It was the output produced by running the commands listed at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources
This config has CONFIG_THUMB2_KERNEL=y and doesn't have an entry for CONFIG_CPU_V6
Well it's because that config is coming from outside the tree itself, it can have no relation to what's in the actual HEAD of what you're building.
- The debian.linaro/config/...config.* files from the packaged linaro
kernel tree (at least me, Tixy and the packaged kernel use this)
- omap2plus_defconfig (omap upstream and some other people use this)
I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...)
Does anyone have a strong view on which config we should be using?
I think folks who are working directly with kernel trees need to use defconfigs coming out of that exact tree and HEAD state. The reason is that along with patching code, we often patch our reference config that "belongs to the tree", ie, at the patchlevel where a new feature is added to the tree, commonly the reference config is patched as well to enable it. In my case that's omap4_defconfig but we need to be paying some attention to everything working with upstream's omap2plus_defconfig as well.
Folks who are packaging the kernel or wanting to get the same result as a packaged kernel with a different tree can try their previous packaged kernel's config; that's a bit less deterministic in terms of what they will get but it's certainly a legitimate thing to do since in the end most people will consume the kernel in packaged form.
Effectively that's what I've been doing.
The reason for this was that I'd assumed that all defconfigs had potentially become stale cruft after all the controversy about them, since Linus no longer wanted to see a load of patches to those files.
But now that things have settled down, I guess should be safe to assume that consolidated defconfigs which have survived the cull are valid and maintained.
omap2plus_defconfig at least is actively used and maintained by the upstream omap guys, and should be a fairly good reference.
However not everyone taking this kernel tree will know about or want to use this external linaro config flavour that lives somewhere completely different. So the tree ought primarily to work with its own local in-tree reference configs above all else.
That seems fair--- and we don't want to get into a situation where the linaro kernel tree is actually broken with the upstream defconfig.
This suggests that for most kernel work done by the kernel WG we should test both with the upstream defconfig and the linaro config, but treat the upstream defconfig as the primary reference.
It's worth noting that the linaro configs typically enable a _lot_
I intend to make this better this cycle. The various flavours will be more consistent with one another and the configs will be much leaner. Also I have found that one can successfully boot test a kernel with only "make uImage" so you don't have to take the time to build all the module to do a quick boot test.
more options and modules than the defconfigs, whichi are usually rather minimal. So the linaro configs may provide a better smoketest for build problems.
Cheers ---Dave
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel