The linaro-2.6.39 kernel repository is now alive
john.rigby at linaro.org
Tue Jun 7 15:44:32 UTC 2011
On Tue, Jun 7, 2011 at 5:33 AM, Dave Martin <dave.martin at 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
>> >>This config has CONFIG_THUMB2_KERNEL=y and doesn't have an entry for
>> 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
> 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
> more options and modules than the defconfigs, whichi are usually
> rather minimal. So the linaro configs may provide a better smoketest
> for build problems.
> linaro-kernel mailing list
> linaro-kernel at lists.linaro.org
More information about the linaro-kernel