[meta-ti] [PATCH 3/4] setup-defconfig: allow use of in-kernel config fragments

[Maupin, Chase]

>-----Original Message-----
>From: Dmytriyenko, Denys
>Sent: Thursday, May 22, 2014 12:36 PM
>To: Maupin, Chase
>Cc: meta-ti at yoctoproject.org
>Subject: Re: [meta-ti] [PATCH 3/4] setup-defconfig: allow use of
>in-kernel config fragments
>
>On Thu, May 22, 2014 at 01:16:21PM -0400, Maupin, Chase wrote:
>> >-----Original Message-----
>> >From: Dmytriyenko, Denys
>> >Sent: Thursday, May 22, 2014 11:51 AM
>> >To: Maupin, Chase
>> >Cc: meta-ti at yoctoproject.org
>> >Subject: Re: [meta-ti] [PATCH 3/4] setup-defconfig: allow use
>of
>> >in-kernel config fragments
>> >
>> >On Thu, May 22, 2014 at 12:19:01PM -0400, Denys Dmytriyenko
>wrote:
>> >> On Thu, May 22, 2014 at 11:16:15AM -0500, Chase Maupin wrote:
>> >> > * Allow the use of in-kernel config fragments instead of
>only
>> >> >   pulling config fragments from the OE meta data.  The OE
>meta
>> >> >   data fragments will still take precedence over in tree
>.cfg
>> >> >   files.
>> >>
>> >> I was thinking to do it differently...
>> >
>> >Basically, I was thinking of embedding the path in the
>> >KERNEL_CONFIG_FRAGMENTS
>> >variable, similar to how KERNEL_DEVICETREE used to do it:
>> >
>> >KERNEL_CONFIG_FRAGMENTS = "${WORKDIR}/ipc.cfg
>> >${KERNEL_CONFIG_DIR}/non-smp.cfg"
>> >
>> >This way you could have fragments of the same name and choose
>> >which one to
>> >use. But the logic in setup-defconfig.inc would be much
>simpler...
>>
>> I also considered this.  I had rejected it because I didn't want
>to see a
>> bunch of duplicate entries for ${WORKDIR} and
>${KERNEL_CONFIG_DIR}.  You are
>> right though that it makes the setup-defconfig simpler.
>>
>> Maybe a use case to consider is whether we think we would have
>fragments in
>> more than 2 locations.  i.e. one in WORKDIR, another in
>directory x of the
>> kernel, and another in directory y of the kernel.  If we think
>this would be
>> reasonable to support then your method makes more sense.  What
>do you think?
>
>Another possible location could be inside a separate git
>repository. Which I
>was considering initially, as I didn't know where Dan would create
>it...

So it sounds like it would be better if I let the PATH be in the config fragment name.  I'll rework this and send v2.

>
>
>> >> > Signed-off-by: Chase Maupin <Chase.Maupin at ti.com>
>> >> > ---
>> >> >  recipes-kernel/linux/setup-defconfig.inc |   36
>> >++++++++++++++++++++++++++++--
>> >> >  1 file changed, 34 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/recipes-kernel/linux/setup-defconfig.inc
>> >b/recipes-kernel/linux/setup-defconfig.inc
>> >> > index 4277f26..fbe7e96 100644
>> >> > --- a/recipes-kernel/linux/setup-defconfig.inc
>> >> > +++ b/recipes-kernel/linux/setup-defconfig.inc
>> >> > @@ -2,6 +2,10 @@
>> >> >  # kernel version string.  such as the commit id
>> >> >  KERNEL_LOCALVERSION ?= ""
>> >> >
>> >> > +# KERNEL_CONFIG_DIR can be set to specify a subdirectory
>to
>> >search for
>> >> > +# kernel configuration fragments
>> >> > +KERNEL_CONFIG_DIR ?= ""
>> >> > +
>> >> >  # 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
>> >> >
>> >> > @@ -27,10 +31,38 @@ do_configure() {
>> >> >          yes '' | oe_runmake oldconfig
>> >> >      fi
>> >> >
>> >> > -    # check for fragments
>> >> > +    # Check for kernel config fragments.  First check the
>> >files copied from
>> >> > +    # the OE meta data since we may want to override
>kernel
>> >config fragments
>> >> > +    # in the recipe.  If you don't find the fragment in
>the
>> >OE meta data
>> >> > +    # then check the kernel sources.  If you still can't
>find
>> >it then bail
>> >> > +    # with an error.
>> >> > +    # Check if any config fragments are specified.
>> >> >      if [ ! -z "${KERNEL_CONFIG_FRAGMENTS}" ]
>> >> >      then
>> >> > -        ( cd ${WORKDIR} &&
>> >${S}/scripts/kconfig/merge_config.sh -m -r -O ${S} ${S}/.config
>> >${KERNEL_CONFIG_FRAGMENTS} 1>&2 )
>> >> > +        # Variable to hold the assembled list of fragments
>> >with absolute paths
>> >> > +        configs=""
>> >> > +
>> >> > +        for f in ${KERNEL_CONFIG_FRAGMENTS}
>> >> > +        do
>> >> > +            # Check if the config fragment was copied into
>> >the WORKDIR from
>> >> > +            # the OE meta data
>> >> > +            if [ -e "${WORKDIR}/$f" ]
>> >> > +            then
>> >> > +                echo "Found config in workdir"
>> >> > +                configs="$configs ""${WORKDIR}/$f"
>> >> > +            # Check if the fragement is in the kernel
>sources
>> >> > +            elif [ -e "${S}/${KERNEL_CONFIG_DIR}/$f" ]
>> >> > +            then
>> >> > +                echo "Found config in kernel"
>> >> > +                configs="$configs
>> >""${S}/${KERNEL_CONFIG_DIR}/$f"
>> >> > +            else
>> >> > +                echo "Could not find kernel config
>fragment
>> >$f"
>> >> > +                exit 1
>> >> > +            fi
>> >> > +        done
>> >> > +
>> >> > +        # Now that all the fragments are located merge
>them.
>> >> > +        ( cd ${WORKDIR} &&
>> >${S}/scripts/kconfig/merge_config.sh -m -r -O ${S} ${S}/.config
>> >${configs} 1>&2 )
>> >> >          yes '' | oe_runmake oldconfig
>> >> >      fi
>> >> >  }
>> >> > --
>> >> > 1.7.9.5
>> >> >
>> >> > --
>> >> > _______________________________________________
>> >> > meta-ti mailing list
>> >> > meta-ti at yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/meta-ti
>> >> --
>> >> _______________________________________________
>> >> meta-ti mailing list
>> >> meta-ti at yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/meta-ti