From: Denys Dmytriyenko <denys@ti.com>
To: "Maupin, Chase" <chase.maupin@ti.com>
Cc: "meta-ti@yoctoproject.org" <meta-ti@yoctoproject.org>
Subject: Re: [RFC][PATCH 1/2] setup-defconfig.inc: implement config fragments by using in-kernel script
Date: Mon, 14 Apr 2014 09:59:20 -0400 [thread overview]
Message-ID: <20140414135920.GA12929@edge> (raw)
In-Reply-To: <7D46E86EC0A8354091174257B2FED1015CF90E45@DLEE11.ent.ti.com>
On Mon, Apr 14, 2014 at 12:01:16PM +0000, Maupin, Chase wrote:
> >-----Original Message-----
> >From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> >bounces@yoctoproject.org] On Behalf Of Denys Dmytriyenko
> >Sent: Sunday, April 13, 2014 10:50 PM
> >To: meta-ti@yoctoproject.org
> >Subject: [meta-ti] [RFC][PATCH 1/2] setup-defconfig.inc: implement
> >config fragments by using in-kernel script
> >
> >From: Denys Dmytriyenko <denys@ti.com>
> >
> >Signed-off-by: Denys Dmytriyenko <denys@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.
Good questions. My primary goal was to keep the syntax the same with Dan's
kernel integration Jenkins job, so it is just a drop-in replacement. Moving
the fragment definition from defconfig to the recipe would certainly change
the syntax and require one to learn another way of doing things...
> >+ 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@yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/meta-ti
> --
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
prev parent reply other threads:[~2014-04-14 13:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 3:50 [RFC][PATCH 1/2] setup-defconfig.inc: implement config fragments by using in-kernel script Denys Dmytriyenko
2014-04-14 3:50 ` [RFC][PATCH 2/2] linux-ti-staging: add baseport, connectivity, ipc and systest config fragments Denys Dmytriyenko
2014-04-14 4:22 ` Khem Raj
2014-04-14 13:54 ` Denys Dmytriyenko
2014-04-14 16:52 ` Khem Raj
2014-04-14 12:01 ` [RFC][PATCH 1/2] setup-defconfig.inc: implement config fragments by using in-kernel script Maupin, Chase
2014-04-14 13:59 ` Denys Dmytriyenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140414135920.GA12929@edge \
--to=denys@ti.com \
--cc=chase.maupin@ti.com \
--cc=meta-ti@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.