[OE-core] do_kernel_configme and defconfig

[Bruce Ashfield]

On Fri, May 11, 2018 at 6:17 PM, <chris.laplante at agilent.com> wrote:

> Hi Bruce,
>
>
>
> Thanks for your insights. The defconfig is coming from
> KBUILD_DEFCONFIG_machinename = “our_defconfig” in our machine conf. I
> understand that the defconfig is just another configuration fragment, but
> given that it has its own variable (KBUILD_DEFCONFIG) I guess I was
> expecting a bit of “magic” out of it; namely, ordering such that the
> fragment called “defconfig” comes first. Otherwise I don’t really see the
> point in supporting in-tree defconfig + .scc/cfg fragments, since the
> former will just wipe out the latter.
>
>
>
> That being said, your explanation of the current behavior makes sense, but
> I think it should be emphasized somewhere in the manual. Care if I submit a
> documentation patch?
>

Absolutely! Feel free to cc' me on the patch and I'll give it a review as
well.

Bruce


>
>
> Thanks,
> Chris
>
>
>
> *From:* Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
> *Sent:* Friday, May 11, 2018 5:09 PM
> *To:* LAPLANTE,CHRIS (A-Little Falls,ex1) <chris.laplante at agilent.com>
> *Cc:* Patches and discussions about the oe-core layer <
> openembedded-core at lists.openembedded.org>; SMITH,JARED (A-Little
> Falls,ex1) <jared.smith at agilent.com>
> *Subject:* Re: [OE-core] do_kernel_configme and defconfig
>
>
>
>
>
>
>
> On Fri, May 11, 2018 at 3:28 PM, Chris Laplante via Openembedded-core <
> openembedded-core at lists.openembedded.org> wrote:
>
> OK, I figured out why this happens. This line in kernel-yocto.bbclass:
>
>
>
> scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes}
> ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
>
>
>
> … passes the BSP def before the sccs. In my case, the BSP def is
> mymachine.scc, and the sccs is the defconfig. So that’s why the defconfig
> comes after the BSP.
>
>
>
> My takeaway is that a BSP plus a defconfig is not a supported use case. Is
> that correct?
>
>
>
> A defconfig isn't magic, it is just another input to the configuration
> merging. It will be applied as any other fragment. There is some special
> processing only a defconfig is specified, but otherwise, it is the same. So
> in this case, whatever it sets would be applied after the BSP definition
> and would take precedence (last through the gate wins).
>
>
>
> If you have a BSP definition, you normally don't have a defconfig. Where
> is the defconfig coming from in your scenario ? The SRC_URI ? You can just
> include it from the .scc files to control the order, which is what is
> expected when you have a BSP definition.
>
>
>
> Were you seeing none of your options set ? or something else ?
>
>
>
>
>
> If so, I think it’s important to add some sanity checking to
> kernel-yocto.bbclass.
>
>
>
>
>
> There's really nothing that could be checked, since the intent of the
> fragments isn't known, and for the most part, defconfigs are the same as
> any other fragment (from the point of view of the merging).
>
>
>
> Bruce
>
>
>
> Thanks,
>
> Chris
>
>
>
> *From:* openembedded-core-bounces at lists.openembedded.org [mailto:
> openembedded-core-bounces at lists.openembedded.org] *On Behalf Of *Chris
> Laplante via Openembedded-core
> *Sent:* Friday, May 11, 2018 2:51 PM
> *To:* openembedded-core at lists.openembedded.org
> *Cc:* SMITH,JARED (A-Little Falls,ex1) <jared.smith at agilent.com>
> *Subject:* [OE-core] do_kernel_configme and defconfig
>
>
>
> Hi all,
>
>
>
> Is it expected for do_kernel_configme to apply the defconfig last (after
> configuration fragments introduced by sccs)?
>
>
>
> For some reason, in the call to merge_config, “.kernel-meta/configs//./defconfig”
> is passed last whereas I’d expect it would be first (since that should be
> the base config). This is causing problems, because config options that my
> config fragments are setting are getting overridden by the defconfig – it
> should be the other way around.
>
>
>
> For reference, I’m using Rocko and have just updated to the latest commit.
> We have an in-tree defconfig, and we set KBUILD_DEFCONFIG_machinename
> appropriately. We are using the separate kernel-meta repository to store
> kernel metadata. I have KMACHINE_machinename set up so that it finds the
> correct BSP definition .scc file. Still seem to be missing something,
> though.
>
>
>
> Thanks,
>
> Chris
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
>
> --
>
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180511/fc21c9a8/attachment-0002.html>