<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Bruce,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<br>
Chris<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
<br>
<b>Sent:</b> Friday, May 11, 2018 5:09 PM<br>
<b>To:</b> LAPLANTE,CHRIS (A-Little Falls,ex1) <chris.laplante@agilent.com><br>
<b>Cc:</b> Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>; SMITH,JARED (A-Little Falls,ex1) <jared.smith@agilent.com><br>
<b>Subject:</b> Re: [OE-core] do_kernel_configme and defconfig<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 11, 2018 at 3:28 PM, Chris Laplante via Openembedded-core <<a href="mailto:openembedded-core@lists.openembedded.org" target="_blank">openembedded-core@lists.openembedded.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">OK, I figured out why this happens. This line in kernel-yocto.bbclass:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:.5in">
scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">… 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.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My takeaway is that a BSP plus a defconfig is not a supported use case. Is that correct?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Were you seeing none of your options set ? or something else ?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If so, I think it’s important to add some sanity checking to kernel-yocto.bbclass.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Bruce<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chris<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b>
<a href="mailto:openembedded-core-bounces@lists.openembedded.org" target="_blank">
openembedded-core-bounces@lists.openembedded.org</a> [mailto:<a href="mailto:openembedded-core-bounces@lists.openembedded.org" target="_blank">openembedded-core-bounces@lists.openembedded.org</a>]
<b>On Behalf Of </b>Chris Laplante via Openembedded-core<br>
<b>Sent:</b> Friday, May 11, 2018 2:51 PM<br>
<b>To:</b> <a href="mailto:openembedded-core@lists.openembedded.org" target="_blank">
openembedded-core@lists.openembedded.org</a><br>
<b>Cc:</b> SMITH,JARED (A-Little Falls,ex1) <<a href="mailto:jared.smith@agilent.com" target="_blank">jared.smith@agilent.com</a>><br>
<b>Subject:</b> [OE-core] do_kernel_configme and defconfig<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi all,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Is it expected for do_kernel_configme to apply the defconfig last (after configuration fragments introduced by sccs)?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chris<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>