LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

[mrkozmic]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

I have defined LINUX_VERSION_EXTENSION in my kernel recipe.

I have no CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO defined in my *defconfig*

After i run bitbake -c kernel_configme <my kernel recipe> I can see in my *.config* file:

CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set

and at the very end:

CONFIG_LOCALVERSION="<my extention>"
So far so good.

Then I execute bitbake -c configure <my kernel recipe>
and the . *config* file is changed. Now there is:
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
and there is no trace of CONFIG_LOCALVERSION="<my extention>"

Yocto: dunfell
Kernel 5.4.70

[-- Attachment #2: Type: text/html, Size: 1793 bytes --]

Re: [yocto] LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

[Bruce Ashfield]

On Fri, Oct 8, 2021 at 11:52 AM <mrkozmic@hotmail.com> wrote:
>
> I have defined LINUX_VERSION_EXTENSION in my kernel recipe.
>
> I have no CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO defined in my defconfig
>
> After i run bitbake -c kernel_configme <my kernel recipe> I can see in my .config file:
>
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
>
> and at the very end:
>
> CONFIG_LOCALVERSION="<my extention>"
> So far so good.
>
> Then I execute  bitbake -c configure <my kernel recipe>
> and the .config file is changed. Now there is:
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> and there is no trace of CONFIG_LOCALVERSION="<my extention>"

Assuming what you are using as a kernel recipe is linux-yocto based,
the code that is adding the CONFIG_LOCALVERSION is a task that runs
after do_configure. So just running -c configure, it shouldn't be in
the .config (and the default kernel configure task, will copy your
defconfig -> .config, and then lets the kernel process it, so you will
have symbols in the .config that are not in your defconfig
explicitly).

If you can make your recipe available, I can probably offer more
specific comments.

Bruce

>
> Yocto: dunfell
> Kernel 5.4.70
>
>
>
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#55003): https://lists.yoctoproject.org/g/yocto/message/55003
> Mute This Topic: https://lists.yoctoproject.org/mt/86173754/1050810
> Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
> Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
> Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


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

Re: LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

[mrkozmic]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

Bruce, I just realized that I replied only to you and not to the group. Hope it is ok that I post your answer here.

On Sat, Oct 9, 2021 at 6:19 AM <mrkozmic@hotmail.com> wrote:
>
> Bruce,
>
> Here .config is written in the kernel_configme task: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.yoctoproject.org%2Fcgit%2Fcgit.cgi%2Fpoky%2Ftree%2Fmeta%2Fclasses%2Fkernel-yocto.bbclass%3Fh%3Ddunfell%23n409&amp;data=04%7C01%7C%7C7757b810abc444e512cc08d98b32ecb1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637693873092757103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FURpcXvzhAKEpN%2BHHmmMpshn3CJNHJxUvFkktaGCf80%3D&amp;reserved=0
>

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() {
>     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 see 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 .config 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="$LD" KCONFIG_ALLCONFIG=$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 all CONFIG_* that where requested, but not included in the final .config, they all come from my defconfig.
>
> Looks like make does not care about KCONFIG_ALLCONFIG=$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).  If you want to use defaults  and then apply your
defconfig, you need to specify KCONFIG_MODE="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.



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

[-- Attachment #2: Type: text/html, Size: 13028 bytes --]

Re: LINUX_VERSION_EXTENSION has no effect #yocto #kernel #dunfell

[mrkozmic]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

Bruce,
It's an honor to get help from the author himself!

I'm starting to understand why they have this:

do_configure_prepend() {
cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
}

Since do_kernel_configme() creates the .config file in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-yocto.bbclass?h=dunfell#n399
(I can't figure out why it fails to merge in our defconfig)

Then the ${WORKDIR}/defconfig is not used by kernel_do_configure() https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n595
So they do the copy of defconfig in do_configure_prepend().

Anyway,  do_kernel_configme() has already been run hence no CONFIG_LOCALVERSION is written to .config

I could just do this:
do_configure_prepend() {
cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
echo "CONFIG_LOCALVERSION=\"${LINUX_VERSION_EXTENSION}\"" >> "${B}/.config"
}

BUT
Your hint make me notice that they did: KCONFIG_MODE="--allnoconfig" which breaks the config merging.
After changing it to alldefconfig and removing do_configure_prepend it all works!

Thank you!

[-- Attachment #2: Type: text/html, Size: 2770 bytes --]