> On Nov 28, 2016, at 11:58 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote: > > On 29-11-16 03:03, Khem Raj wrote: >> >>> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfi...@gmail.com >>> <mailto: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. > > The problem seems to be that the class "do_configure" does things that should > happen before and after things that the recipe would want to change. > > Copying defconfig or whatever means to create a .config should be first. > > Next, the specific kernel recipe would want to mangle that configuration to > suit its needs, like applying fragments and such. > > Then the makeoldconfig (or whatever) task should run.
> > > The current system assumes that the kernel recipe creates a > do_configure_prepend to do the mangling, which is rather counterintuitive, > one would expect to "append" extra actions. > > A structured approach would be to split the do_configure into two parts that > should run in sequence, and then kernel recipes can inject their actions by > appending to them as they see fit. The first task would create the .config > file by (forcibly) copying any defconfig or starting point. The second task > would call the kernel's make script to futher process it. > it might just be enough to expect kernel.bbclass to error out if a given task is not implemented by inheriting recipes much like pure virtual functions in C++ and get rid of _append/_prepend sequencing expectations. > But this too would break existing recipes. > > > >>> >>> 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). > > > > > 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 > E-mail: mike.looijm...@topicproducts.com > Website: www.topicproducts.com > > Please consider the environment before printing this e-mail > > > > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
