* Kernel: Builds use old version of defconfig @ 2016-11-24 10:10 Mike Looijmans 2016-11-24 10:32 ` Mike Looijmans 0 siblings, 1 reply; 7+ messages in thread From: Mike Looijmans @ 2016-11-24 10:10 UTC (permalink / raw) To: openembedded-core 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... 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.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-24 10:10 Kernel: Builds use old version of defconfig Mike Looijmans @ 2016-11-24 10:32 ` Mike Looijmans 2016-11-24 13:55 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Mike Looijmans @ 2016-11-24 10:32 UTC (permalink / raw) To: openembedded-core 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? 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.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-24 10:32 ` Mike Looijmans @ 2016-11-24 13:55 ` Bruce Ashfield 2016-11-29 2:03 ` Khem Raj 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2016-11-24 13:55 UTC (permalink / raw) To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 4120 bytes --] On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@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 ... 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 > E-mail: mike.looijmans@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 > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" [-- Attachment #2: Type: text/html, Size: 6290 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-24 13:55 ` Bruce Ashfield @ 2016-11-29 2:03 ` Khem Raj 2016-11-29 7:58 ` Mike Looijmans 0 siblings, 1 reply; 7+ messages in thread From: Khem Raj @ 2016-11-29 2:03 UTC (permalink / raw) To: Bruce Ashfield Cc: Mike Looijmans, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 4958 bytes --] > On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl <mailto:mike.looijmans@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@topicproducts.com <mailto:mike.looijmans@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> [-- Attachment #2: Type: text/html, Size: 13293 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-29 2:03 ` Khem Raj @ 2016-11-29 7:58 ` Mike Looijmans 2016-11-29 17:25 ` Khem Raj 2016-11-29 17:49 ` Andre McCurdy 0 siblings, 2 replies; 7+ messages in thread From: Mike Looijmans @ 2016-11-29 7:58 UTC (permalink / raw) To: Khem Raj, Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On 29-11-16 03:03, Khem Raj wrote: > >> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield@gmail.com >> <mailto:bruce.ashfield@gmail.com>> wrote: >> >> >> >> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl >> <mailto:mike.looijmans@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. 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.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-29 7:58 ` Mike Looijmans @ 2016-11-29 17:25 ` Khem Raj 2016-11-29 17:49 ` Andre McCurdy 1 sibling, 0 replies; 7+ messages in thread From: Khem Raj @ 2016-11-29 17:25 UTC (permalink / raw) To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer > On Nov 28, 2016, at 11:58 PM, Mike Looijmans <mike.looijmans@topic.nl> wrote: > > On 29-11-16 03:03, Khem Raj wrote: >> >>> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield@gmail.com >>> <mailto:bruce.ashfield@gmail.com>> wrote: >>> >>> >>> >>> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl >>> <mailto:mike.looijmans@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.looijmans@topicproducts.com > Website: www.topicproducts.com > > Please consider the environment before printing this e-mail > > > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel: Builds use old version of defconfig 2016-11-29 7:58 ` Mike Looijmans 2016-11-29 17:25 ` Khem Raj @ 2016-11-29 17:49 ` Andre McCurdy 1 sibling, 0 replies; 7+ messages in thread From: Andre McCurdy @ 2016-11-29 17:49 UTC (permalink / raw) To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer On Mon, Nov 28, 2016 at 11:58 PM, Mike Looijmans <mike.looijmans@topic.nl> wrote: > > 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. For reference, I've implemented support for merging of config fragments in kernel.bbclass based kernel recipes just by over-riding KERNEL_CONFIG_COMMAND. No do_configure_prepend required. The basic version is: KERNEL_CONFIG_COMMAND = " \ cd ${S} ; \ ${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls ${WORKDIR}/*.cfg 2>/dev/null` ; \ cd ${B} \ " The debug version, with lots of error checking etc to verify that calling merge_config.sh with no config fragments is equivalent to the default KERNEL_CONFIG_COMMAND (which calls "make oldnoconfig" with a fallback to "yes '' | make oldconfig" for _very_ old kernels) is: KERNEL_CONFIG_COMMAND = " \ set -x ; \ cp .config .config_original ; \ cd ${S} ; \ oe_runmake_call O=${B} oldnoconfig ; \ mv ${B}/.config ${B}/.config_oldnoconfig ; \ cp ${B}/.config_original ${B}/.config ; \ ${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config ; \ mv ${B}/.config ${B}/.config_merged_no_fragments ; \ cp ${B}/.config_original ${B}/.config ; \ ${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls ${WORKDIR}/*.cfg 2>/dev/null` ; \ cp ${B}/.config ${B}/.config_merged_with_fragments ; \ cd ${B} ; \ diff -u .config_oldnoconfig .config_merged_no_fragments ; \ diff -u .config_oldnoconfig .config_merged_with_fragments || true \ " > 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. > > But this too would break existing recipes. > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-11-29 17:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-24 10:10 Kernel: Builds use old version of defconfig Mike Looijmans 2016-11-24 10:32 ` Mike Looijmans 2016-11-24 13:55 ` Bruce Ashfield 2016-11-29 2:03 ` Khem Raj 2016-11-29 7:58 ` Mike Looijmans 2016-11-29 17:25 ` Khem Raj 2016-11-29 17:49 ` Andre McCurdy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox