From: ChenQi <Qi.Chen@windriver.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Patches, Zhenfeng.Zhao@windriver.com
Subject: Re: [PATCH 1/1] busybox: add config fragments
Date: Tue, 5 Feb 2013 11:01:41 +0800 [thread overview]
Message-ID: <51107615.2060807@windriver.com> (raw)
In-Reply-To: <CADkTA4OuDqRE25oNRbFJCyrWpkkj62HpHHNN4qOFocNnrgSY_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7829 bytes --]
On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
>
>
>
> On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold <sgw@linux.intel.com
> <mailto:sgw@linux.intel.com>> wrote:
>
> On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
>
>
>
>
> On Fri, Feb 1, 2013 at 4:00 AM, <Qi.Chen@windriver.com
> <mailto:Qi.Chen@windriver.com>
> <mailto:Qi.Chen@windriver.com <mailto:Qi.Chen@windriver.com>>>
> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com
> <mailto:Qi.Chen@windriver.com> <mailto:Qi.Chen@windriver.com
> <mailto:Qi.Chen@windriver.com>>>
>
>
> Add config fragments to busybox.
>
> Both the implementation and the use case are similar to
> yocto kernel's
> configuration fragments.
>
>
> I can fairly easily tweak the configuration parts of the
> kern-tools to
> handle this
> use case as well. That would allow us to re-use the kernel's
> merge_config.sh
> script (with a minor dependency change) and save some
> duplicated code. It
> also gets you the advantage that you can consolidate
> configuration fragments
> outside of any build system, which isn't as critical here, but
> something
> that
> is used quite a bit during kernel testing.
>
> Bruce,
>
> Where is the merge_config.sh script today? Would you propose
> moving it to the scripts dir and have the busybox recipe call it?
>
>
> It's part of the mainline kernel, hence why grabbing the guts out of
> it reproducing
> it here isn't the best idea, we'll have a need to keep them in sync.
> In fact, I have
> 2 or 3 pending patches for it in the kern-tools repository that I need
> to get upstream
> (as an example).
>
> I'd propose either creating a separate recipe for it (i.e. like
> kconfig-frontends) or I could
> keep it in kern-tools (badly named, but we can work on that ;) and
> maintain / coordinate
> changes to it.
>
> I just don't want to see the effort happen twice, we are busy enough!
I thought about keeping the codes in sync but couldn't figure out a nice
way.
It would be great if you do so.
Thanks in advance :)
Best Regards,
Chen Qi
>
> What would be your timing on making such a change, ie hold this
> patch until your get it merge or merge this and then fix it when
> you merge your changes?
>
>
> I could feasibly get it done in the next few weeks, the changes aren't
> bug, I just
> have to avoid regressions on either side (kernel or busy box).
>
> That being said, the interface to the SRC_URI is the same for the two,
> so if we are
> ok with me arriving and removing the in-recipe support, I guess I
> can't object too
> much :) The only risk is that if anyone starts using this first
> support immediately,
> I do risk regressing their use case, where if it never goes in, that
> won't happen.
>
> Cheers,
>
> Bruce
>
>
>
> Sau!
>
> To be clear, I'm not talking about the entire kern-tools here,
> just the
> config parts.
>
> Cheers,
>
> Bruce
>
>
> [YOCTO #3379]
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com
> <mailto:Qi.Chen@windriver.com>
> <mailto:Qi.Chen@windriver.com
> <mailto:Qi.Chen@windriver.com>>>
>
> ---
> meta/recipes-core/busybox/busybox.inc | 45
> +++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/meta/recipes-core/busybox/busybox.inc
> b/meta/recipes-core/busybox/busybox.inc
> index 972e7d0..66044f8 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -112,8 +112,53 @@ do_prepare_config () {
> fi
> }
>
> +# returns all the elements from the src uri that are .cfg
> files
> +def find_cfgs(d):
> + sources=src_patches(d, True)
> + sources_list=[]
> + for s in sources:
> + if s.endswith('.cfg'):
> + sources_list.append(s)
> +
> + return sources_list
> +
> +# Merge config fragments
> +# All config fragments for busybox should end with .cfg
> +do_merge_config() {
> + SED_CONFIG_EXP="s/^\(#
> \)\{0,1\}\(CONFIG_[a-zA-Z0-9_]*\)[=
> ].*/\2/p"
> + MERGE_LIST="${@" ".join(find_cfgs(d))}"
> + if [ -n "$MERGE_LIST" ]; then
> + # Make a temp file, merge .config and
> .cfg files
> into it
> + TMP_FILE=`mktemp .tmp.config.XXXXXXXX`
> + cp .config $TMP_FILE
> + for MERGE_FILE in $MERGE_LIST; do
> + CFG_LIST=`sed -n "${SED_CONFIG_EXP}"
> $MERGE_FILE`
> + for CFG in $CFG_LIST ; do
> + grep -q -w $CFG $TMP_FILE
> + if [ $? -eq 0 ] ; then
> + PREV_VAL=`grep -w $CFG
> $TMP_FILE`
> + NEW_VAL=`grep -w $CFG
> $MERGE_FILE`
> + if [ "x$PREV_VAL" !=
> "x$NEW_VAL" ] ; then
> + echo Value of $CFG
> is redefined by fragment $MERGE_FILE:
> + echo Previous
> value: $PREV_VAL
> + echo New value:
> $NEW_VAL
> + echo
> + fi
> + sed -i "/$CFG[
> =]/d" $TMP_FILE
> + fi
> + done
> + echo >> $TMP_FILE
> + cat $MERGE_FILE >> $TMP_FILE
> + done
> + # Copy the temp file to .config, do some
> cleanup
> + cp $TMP_FILE .config
> + rm $TMP_FILE
> + fi
> +}
> +
> do_configure () {
> do_prepare_config
> + do_merge_config
> cml1_do_configure
> }
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> <mailto:Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>>
>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness
> await
> thee at its end"
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
[-- Attachment #2: Type: text/html, Size: 18185 bytes --]
next prev parent reply other threads:[~2013-02-05 3:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 9:00 [PATCH 0/1] busybox: add config fragments Qi.Chen
2013-02-01 9:00 ` [PATCH 1/1] " Qi.Chen
2013-02-01 14:18 ` Bruce Ashfield
2013-02-01 18:56 ` Saul Wold
2013-02-01 19:08 ` Bruce Ashfield
2013-02-05 3:01 ` ChenQi [this message]
2013-02-05 6:42 ` ChenQi
2013-02-05 16:29 ` Bruce Ashfield
2013-02-12 13:21 ` Richard Purdie
2013-02-12 14:06 ` Bruce Ashfield
2013-02-12 15:32 ` Richard Purdie
2013-02-12 16:50 ` Bruce Ashfield
2013-02-13 16:53 ` Richard Purdie
2013-02-13 16:59 ` Bruce Ashfield
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=51107615.2060807@windriver.com \
--to=qi.chen@windriver.com \
--cc=Zhenfeng.Zhao@windriver.com \
--cc=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.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.