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

Andre McCurdy armccurdy at gmail.com
Tue Nov 29 17:49:21 UTC 2016


On Mon, Nov 28, 2016 at 11:58 PM, Mike Looijmans
<mike.looijmans at 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.
>



More information about the Openembedded-core mailing list