From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDFF7C433F5 for ; Sat, 9 Oct 2021 15:33:08 +0000 (UTC) Subject: Re: LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell To: yocto@lists.yoctoproject.org From: mrkozmic@hotmail.com X-Originating-Location: Gullaug, Viken, NO (109.247.173.63) X-Originating-Platform: Windows Chrome 94 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sat, 09 Oct 2021 08:33:08 -0700 References: In-Reply-To: Message-ID: <25113.1633793588160556369@lists.yoctoproject.org> Content-Type: multipart/alternative; boundary="KLhswkvpAthOx0RSEMFC" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sat, 09 Oct 2021 15:33:08 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/yocto/message/55008 --KLhswkvpAthOx0RSEMFC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bruce, I just realized that I replied only to you and not to the group. Hop= e it is ok that I post your answer here. On Sat, Oct 9, 2021 at 6:19 AM wrote: > > Bruce, > > Here .config is written in the kernel_configme task: https://emea01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit.yoctoproject.org%2Fcgi= t%2Fcgit.cgi%2Fpoky%2Ftree%2Fmeta%2Fclasses%2Fkernel-yocto.bbclass%3Fh%3Ddu= nfell%23n409&data=3D04%7C01%7C%7C7757b810abc444e512cc08d98b32ecb1%7C84d= f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637693873092757103%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C1000&sdata=3D%2FURpcXvzhAKEpN%2BHHmmMpshn3CJNHJxUvFkktaGCf80%3D&r= eserved=3D0 > Yes, I'm the one that wrote all of the fragment handling and processing, so unless something else is being injected into the tasks, I know how it should work :) > My kernel recipe (not written by me) is made up of several files. I found= this: > do_configure_prepend() { >=C2=A0=C2=A0=C2=A0=C2=A0 cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}= " "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND" > } > Which makes sense why it does not work. So I removed these lines and I se= e why someone put them there. My defconfig is not put into the .config file= by the merge_config.sh script. > It looks like the script does everything correctly, but the resulting .co= nfig is always the default, nothing is included from my defconfig. Considering that linux-yocto has had support for using an in-tree defconfig for a long time, indeed, that is a strange thing for someone to write! Is KBUILD_DEFCONFIG defined in your recipe ? If so, the kernel-yocto bbclass will do a similar copy and use that as the baseline. > > The final .config is generated in merge_config.sh by > make LD=3D"$LD" KCONFIG_ALLCONFIG=3D$TMP_FILE $OUTPUT_ARG $ALLTARGET > I have checked, and the $TMP_FILE is the same as my defconfig. The log fr= om merge_script.sh lists all CONFIG_* that where requested, but not include= d in the final .config, they all come from my defconfig. > > Looks like make does not care about KCONFIG_ALLCONFIG=3D$TMP_FILE No, that wouldn't be the case. Just because you have something in a defconfig, or a configuration fragment, doesn't mean that it ends up in the final .config. They are still subject to the dependencies, defaults, selects, etc, of the Kconfig files within the kernel tree as the configuration phase of the kernel is executed. If you have a defconfig in your workdir, the mode of merge config is set to "-n", which is an allnoconfig, and then what you have in your defconfig will be applied based on those conditions. If your defconfig is based on a savedefconfig (which many of them are now, in particular in tree ones).=C2=A0 If you want to use defaults=C2=A0 and then apply your defconfig, you need to specify KCONFIG_MODE=3D"alldefconfig" in your kernel recipe (maybe you are already doing that, but it is worth mentioning). But given that KBUILD_DEFCONFIG copy that you found, clearly there are some custom things happening, so I really can't say for sure. =EE=9C=92 Bruce > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II --KLhswkvpAthOx0RSEMFC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
<= span style=3D"-webkit-font-smoothing: antialiased; font-size: small;">Bruce, I just realized that I replied only to you and not to th= e group. Hope it is ok that I post your answer here. 
&= nbsp;
<= span style=3D"-webkit-font-smoothing: antialiased; font-size: small;">On Sat, Oct 9, 2021 = at 6:19 AM <mrkozmic@hotmail.com> wrote:
>
> Bruce,
><= br style=3D"-webkit-font-smoothing: antialiased;" />> Here .config is wr= itten in the kernel_configme task: https://emea01.safelinks.protection= .outlook.com/?url=3Dhttps%3A%2F%2Fgit.yoctoproject.org%2Fcgit%2Fcgit.cgi%2F= poky%2Ftree%2Fmeta%2Fclasses%2Fkernel-yocto.bbclass%3Fh%3Ddunfell%23n409&am= p;amp;data=3D04%7C01%7C%7C7757b810abc444e512cc08d98b32ecb1%7C84df9e7fe9f640= afb435aaaaaaaaaaaa%7C1%7C0%7C637693873092757103%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3D%2FURpcXvzhAKEpN%2BHHmmMpshn3CJNHJxUvFkktaGCf80%3D&amp;rese= rved=3D0
>

Yes, I'm the one that wrote all of the fragment ha= ndling and
processing, = so unless something else is being injected into the tasks,
I know how it should work :)

> My kernel recipe (not written by me) is made up = of several files. I found this:
> do_configure_prepend() {
>     cp "${S}/arch/${ARCH}/configs/= ${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} = NOT FOUND"
> }
> Which makes sense why i= t does not work. So I removed these lines and I see why someone put them th= ere. My defconfig is not put into the .config file by the merge_config.sh s= cript.
> It looks li= ke the script does everything correctly, but the resulting .config is alway= s the default, nothing is included from my defconfig.

Considering that linux-yocto has had support for using an in-tree<= br style=3D"-webkit-font-smoothing: antialiased;" />defconfig for a long ti= me, indeed, that is a strange thing for someone
to write!

Is KBUILD_= DEFCONFIG defined in your recipe ? If so, the kernel-yocto
bbclass will do a similar copy and use = that as the baseline.
<= br style=3D"-webkit-font-smoothing: antialiased;" />>
> The final .config is generated in me= rge_config.sh by
> m= ake LD=3D"$LD" KCONFIG_ALLCONFIG=3D$TMP_FILE $OUTPUT_ARG $ALLTARGET
> I have checked, and the $= TMP_FILE is the same as my defconfig. The log from merge_script.sh lists al= l CONFIG_* that where requested, but not included in the final .config, the= y all come from my defconfig.
>
> Looks = like make does not care about KCONFIG_ALLCONFIG=3D$TMP_FILE

No, that wouldn't be the case.

Just because you have something in a defconfig, or a configuration
fragment, doesn't mean that it= ends up in the final .config. They are
still subject to the dependencies, defaults, selects, etc,= of the
Kconfig files w= ithin the kernel tree as the configuration phase of the
kernel is executed.

If you have a defconfig in your workdir, the mode of merge config i= s
set to "-n", which is= an allnoconfig, and then what you have in your
defconfig will be applied based on those condition= s. If your defconfig
is= based on a savedefconfig (which many of them are now, in particular
in tree ones).  If you w= ant to use defaults  and then apply your
defconfig, you need to specify KCONFIG_MODE=3D"allde= fconfig" in your
kernel= recipe (maybe you are already doing that, but it is worth
mentioning).

some custom things happ= ening, so I really can't say for sure.
 
 
<= span style=3D"-webkit-font-smoothing: antialiased; font-size: small;">Bruce

>


--
- Thou shalt = not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II<= /span>
--KLhswkvpAthOx0RSEMFC--