On Tue, Jun 7, 2011 at 5:33 AM, Dave Martin <dave.mar...@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-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
