<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <span dir="ltr"><<a href="mailto:mike.looijmans@topic.nl" target="_blank">mike.looijmans@topic.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24-11-16 11:10, Mike Looijmans wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm currently experiencing a problem with "defconfig" files and the kernel.<br>
<br>
In short, when I make a change to the "defconfig" file, the kernel is rebuilt<br>
(which is correct), but the resulting kernel has been built using the old<br>
defconfig from a previous build, instead of the new one.<br>
<br>
The kernel recipe just contains "file://defconfig" in its SRC_URI. The<br>
defconfig file is in the project's overlay.<br>
<br>
For example, I have a kernel with "CONFIG_DEVMEM" disabled:<br>
<br>
# gunzip < /proc/config.gz | grep DEVMEM<br>
# CONFIG_DEVMEM is not set<br>
<br>
Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the image.<br>
The result:<br>
<br>
# gunzip < /proc/config.gz | grep DEVMEM<br>
# CONFIG_DEVMEM is not set<br>
<br>
So the change did not make it into the actual kernel, even though the kernel<br>
was rebuild as a result of the change.<br>
<br>
I run "bitbake -c cleansstate virtual/kernel" and build the image again:<br>
<br>
# gunzip < /proc/config.gz | grep DEVMEM<br>
CONFIG_DEVMEM=y<br>
<br>
After cleaning, the result is correct and the new defconfig is active.<br>
<br>
I'm trying to figure out how this can happen, any help is welcome...<br>
</blockquote>
<br></span>
What seems to be the problem is this code in kernel.bbclass:<br>
<br>
# Copy defconfig to .config if .config does not exist. This allows<br>
# recipes to manage the .config themselves in do_configure_prepend().<br>
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then<br>
cp "${WORKDIR}/defconfig" "${B}/.config"<br>
fi<br>
<br>
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.<br>
<br>
I see two possible ways to fix this.<br>
<br>
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.<br>
<br>
<br>
2) Remove the second part of the "if" statement, so it becomes:<br>
<br>
# Copy defconfig to .config if "defconfig" exists. This allows<br>
# recipes to manage the .config themselves in do_configure_prepend().<br>
if [ -f "${WORKDIR}/defconfig" ]; then<br>
cp "${WORKDIR}/defconfig" "${B}/.config"<br>
fi<br>
<br>
I've tested that, and it solves my problem. However, it will probably break other people's config mangling?<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><br></div><div class="gmail_quote">Yep, in particular all the fragment processing which has the capability of starting<br></div><div class="gmail_quote">with a defconfig and then apply fragments from any number of other places. When<br></div><div class="gmail_quote">that task completes, a full .config is in ${B}. If that statement comes along and<br></div><div class="gmail_quote">clobbers the .config ...<br><br></div><div class="gmail_quote">I'm actually working in the 2.3 release cycle to make the fragment processing<br></div><div class="gmail_quote">be available to all kernels, which will likely solve this problem .. but we can't <br></div><div class="gmail_quote">wait for that.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"></div><div class="gmail_quote">So I'm hoping that there's a way to make the behaviour cover both use cases.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Maybe someone with more bitbake knowledge can point out a way that can<br></div><div class="gmail_quote">detect if the task is being run due to a change in the task signature. <br><br>Since if you've modified the defconfig, the task is being re-run for that change<br>and at that point we could safely remove the .config (versus forcing it on the<br></div><div class="gmail_quote">clean step).<br><br></div><div class="gmail_quote">Bruce<br></div><div class="gmail_quote"><br><br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
<br>
Kind regards,<br>
<br>
Mike Looijmans<br>
System Expert<br>
<br>
TOPIC Products<br>
Materiaalweg 4, NL-5681 RJ Best<br>
Postbus 440, NL-5680 AK Best<br>
Telefoon: <a href="tel:%2B31%20%280%29%20499%2033%2069%2079" value="+31499336979" target="_blank">+31 (0) 499 33 69 79</a><br>
E-mail: <a href="mailto:mike.looijmans@topicproducts.com" target="_blank">mike.looijmans@topicproducts.c<wbr>om</a><br>
Website: <a href="http://www.topicproducts.com" rel="noreferrer" target="_blank">www.topicproducts.com</a><br>
<br>
Please consider the environment before printing this e-mail<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openem<wbr>bedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>