[OE-core] Kernel: Builds use old version of defconfig

[Khem Raj]

> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
> 
> 
> 
> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans at topic.nl <mailto:mike.looijmans at topic.nl>> wrote:
> On 24-11-16 11:10, Mike Looijmans wrote:
> I'm currently experiencing a problem with "defconfig" files and the kernel.
> 
> In short, when I make a change to the "defconfig" file, the kernel is rebuilt
> (which is correct), but the resulting kernel has been built using the old
> defconfig from a previous build, instead of the new one.
> 
> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
> defconfig file is in the project's overlay.
> 
> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
> 
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
> 
> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the image.
> The result:
> 
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
> 
> So the change did not make it into the actual kernel, even though the kernel
> was rebuild as a result of the change.
> 
> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
> 
> # gunzip < /proc/config.gz | grep DEVMEM
> CONFIG_DEVMEM=y
> 
> After cleaning, the result is correct and the new defconfig is active.
> 
> I'm trying to figure out how this can happen, any help is welcome...
> 
> What seems to be the problem is this code in kernel.bbclass:
> 
>         # Copy defconfig to .config if .config does not exist. This allows
>         # recipes to manage the .config themselves in do_configure_prepend().
>         if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>                 cp "${WORKDIR}/defconfig" "${B}/.config"
>         fi
> 
> This keeps any existing ".config" file if it happens to still be in the $B path, which is the case if you're rebuilding a kernel.
> 
> I see two possible ways to fix this.
> 
> 1) During "cleanup" also remove the .config file in the build dir. However, the build dir is probably kept alive for a reason? I also can't figure out how that "cleanup" is being done.
> 
> 
> 2) Remove the second part of the "if" statement, so it becomes:
> 
>         # Copy defconfig to .config if "defconfig" exists. This allows
>         # recipes to manage the .config themselves in do_configure_prepend().
>         if [ -f "${WORKDIR}/defconfig" ]; then
>                 cp "${WORKDIR}/defconfig" "${B}/.config"
>         fi
> 
> I've tested that, and it solves my problem. However, it will probably break other people's config mangling?
> 
> 
> Yep, in particular all the fragment processing which has the capability of starting
> with a defconfig and then apply fragments from any number of other places. When
> that task completes, a full .config is in ${B}.  If that statement comes along and
> clobbers the .config …

so you either assume that .config is valid once generated or you dont. When a configure task
is triggered it should recreate .config everytime. 

> 
> I'm actually working in the 2.3 release cycle to make the fragment processing
> be available to all kernels, which will likely solve this problem .. but we can't 
> wait for that.
> 
> So I'm hoping that there's a way to make the behaviour cover both use cases.
> 
> Maybe someone with more bitbake knowledge can point out a way that can
> detect if the task is being run due to a change in the task signature. 
> 
> Since if you've modified the defconfig, the task is being re-run for that change
> and at that point we could safely remove the .config (versus forcing it on the
> clean step).
> 
> Bruce
> 
> 
>  
> 
> 
> Kind regards,
> 
> Mike Looijmans
> System Expert
> 
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <tel:%2B31%20%280%29%20499%2033%2069%2079>
> E-mail: mike.looijmans at topicproducts.com <mailto:mike.looijmans at topicproducts.com>
> Website: www.topicproducts.com <http://www.topicproducts.com/>
> 
> Please consider the environment before printing this e-mail
> 
> 
> 
> 
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org <mailto:Openembedded-core at lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> 
> 
> 
> -- 
> "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 <mailto:Openembedded-core at lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161128/02696993/attachment-0002.html>