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_ 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-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
