[OE-core] do_kernel_configme and defconfig

[Sylvain Lemieux]

Hi Chris,

the scenario we are using work and apply the kernel config segment on
top of the defconfig file.

Our BSP layer provide a "defconfig" using the source URI in the kernel
recipe; any layer that are based on this BSP can add their own kernel
config fragment.in a bbappend.

I am not sure if it is useful to also cover this scenario if we update
the documentation.


Sylvain Lemieux

On Fri, May 11, 2018 at 6:40 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
>
>
> 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"
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>