[meta-ti] [RFC][PATCH 1/2] setup-defconfig.inc: implement config fragments by using in-kernel script

[Maupin, Chase]

>-----Original Message-----
>From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
>bounces at yoctoproject.org] On Behalf Of Denys Dmytriyenko
>Sent: Sunday, April 13, 2014 10:50 PM
>To: meta-ti at yoctoproject.org
>Subject: [meta-ti] [RFC][PATCH 1/2] setup-defconfig.inc: implement
>config fragments by using in-kernel script
>
>From: Denys Dmytriyenko <denys at ti.com>
>
>Signed-off-by: Denys Dmytriyenko <denys at ti.com>
>---
> recipes-kernel/linux/setup-defconfig.inc | 27 ++++++++++++++++---
>--------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
>diff --git a/recipes-kernel/linux/setup-defconfig.inc b/recipes-
>kernel/linux/setup-defconfig.inc
>index ed3bce2..d6e5557 100644
>--- a/recipes-kernel/linux/setup-defconfig.inc
>+++ b/recipes-kernel/linux/setup-defconfig.inc
>@@ -5,27 +5,32 @@ KERNEL_LOCALVERSION ?= ""
> # Check the defconfig file and see if it points to an in kernel
> # defconfig that should be used, or if it is a complete config
>file
>
>-addtask setup_defconfig before do_configure after do_patch
>-do_setup_defconfig() {
>-    # Always copy the defconfig file to .config to keep
>consistency
>-    # between the case where there is a real config and the in
>kernel
>-    # tree config
>-    cp ${WORKDIR}/defconfig ${S}/.config
>-}
>-
> # define our own do_configure that will:
> #   1. Check the .config file and see if string use-kernel-
>config= is present
> #   2. If the use-kernel-config string is present parse out the
>config to use
>-#      and run make ${config}
>+#      and run make $config
> #   3. else run yes '' | oe_runmake oldconfig like the default
>do_configure
> #      does
> do_configure() {
>+    # Always copy the defconfig file to .config to keep
>consistency
>+    # between the case where there is a real config and the in
>kernel
>+    # tree config
>+    cp ${WORKDIR}/defconfig ${S}/.config
>+
>     echo ${KERNEL_LOCALVERSION} > ${B}/.scmversion
>     echo ${KERNEL_LOCALVERSION} > ${S}/.scmversion
>     config=`cat ${S}/.config | grep use-kernel-config | cut -d= -
>f2`
>-    if [ "x${config}" != "x" ]
>+    if [ "x$config" != "x" ]
>     then
>-        oe_runmake ${config}
>+        # check for fragments
>+        fragments=`cat ${S}/.config | grep config-fragment | cut
>-d= -f2`

Implementation question here.  Would it be easier to instead list the fragments you want to merge in the recipe?  My reasoning is this:

1. You already have a list of all the fragments to pull down in the recipe, so why make it require updating two spots to add a fragment.  For example to add a new fragment you would add it to the SRC_URI in the recipe and then have to modify the defconfig to use it.
2. If we keep the list in the recipe we avoid having to store defconfigs based on machine or build type.  For example on the AM335x we could use the same defconfig file as the dra7xx but just specify that we want to add a no-SMP config fragment.  That way as we add new fragments we are not updating each defconfig.
3. For things like system test builds where they want to enable options that might hurt performance but are good for debug having the recipe control this would make it easier to add these through a bbappend or an environment variable.  The current way they would have to overlay the entire defconfig which means keeping them in sync rather than appending the recipe to add another config fragment to the list.

>+        oe_runmake $config
>+        if [ "x$fragments" != "x" ]
>+        then
>+            fragnames=`basename -a $fragments`
>+            ( cd ${WORKDIR} &&
>${S}/scripts/kconfig/merge_config.sh -m -r -O ${S} ${S}/.config
>$fragnames 1>&2 )
>+            yes '' | oe_runmake oldconfig
>+        fi
>     else
>         yes '' | oe_runmake oldconfig
>     fi
>--
>1.9.2
>
>--
>_______________________________________________
>meta-ti mailing list
>meta-ti at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/meta-ti