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


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@...> wrote:
> Bruce,
> Here .config is written in the kernel_configme task:;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 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 by
> I have checked, and the $TMP_FILE is the same as my defconfig. The log from 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

But given that KBUILD_DEFCONFIG copy that you found, clearly there are
some custom things happening, so I really can't say for sure.


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

Join to automatically receive all group messages.