> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfi...@gmail.com> wrote: > > > > On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijm...@topic.nl > <mailto:mike.looijm...@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.looijm...@topicproducts.com > <mailto:mike.looijm...@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@lists.openembedded.org > <mailto:Openembedded-core@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@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
