[meta-ti] [PATCH 3/4] setup-defconfig: allow use of in-kernel config fragments
Maupin, Chase
chase.maupin at ti.com
Thu May 22 10:16:21 PDT 2014
>-----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?
>
>
>> > 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
More information about the meta-ti
mailing list