From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.windriver.com ([147.11.1.11]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1U2cTT-0002H9-ON for openembedded-core@lists.openembedded.org; Tue, 05 Feb 2013 07:57:48 +0100 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r156ft0X002294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 22:41:55 -0800 (PST) Received: from [128.224.163.154] (128.224.163.154) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 4 Feb 2013 22:41:54 -0800 Message-ID: <5110A9D1.20208@windriver.com> Date: Tue, 5 Feb 2013 14:42:25 +0800 From: ChenQi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bruce Ashfield References: <510C0FF1.2010400@linux.intel.com> In-Reply-To: X-Originating-IP: [128.224.163.154] Cc: and discussions about the oe-core layer , Patches, Zhenfeng.Zhao@windriver.com Subject: Re: [PATCH 1/1] busybox: add config fragments X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 06:57:49 -0000 X-Groupsio-MsgNum: 34968 Content-Type: multipart/mixed; boundary="------------050105040600050402060206" --------------050105040600050402060206 Content-Type: multipart/alternative; boundary="------------040200000107030609000303" --------------040200000107030609000303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 02/02/2013 03:08 AM, Bruce Ashfield wrote: > > > > On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold > wrote: > > On 02/01/2013 06:18 AM, Bruce Ashfield wrote: > > > > > On Fri, Feb 1, 2013 at 4:00 AM, > >> > wrote: > > From: Chen Qi >> > > > 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! > > > 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 > > Hi Bruce, I just tried to reuse the kernel's merge_config.sh script, and it turned out well. The patch is in attachment. Is it enough for now? If so, I'll send out the patch. Thanks, Chen Qi --------------040200000107030609000303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
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> 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>> wrote:

    From: Chen Qi <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!
 

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



Hi Bruce,

I just tried to reuse the kernel's merge_config.sh script, and it turned out well.
The patch is in attachment.

Is it enough for now?
If so, I'll send out the patch.

Thanks,
Chen Qi
--------------040200000107030609000303-- --------------050105040600050402060206 Content-Type: text/x-patch; name="0001-busybox-add-config-fragments.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-busybox-add-config-fragments.patch" >From a9d36bf24f349f046e9b65ccf4af3352c4dedabf Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Tue, 5 Feb 2013 14:36:40 +0800 Subject: [PATCH] busybox: add config fragments Add config fragments to busybox. The implementation makes use of merge_config.sh script in kern-tools-native. The use case is similar to the yocto kernel's configuration fragments. [YOCTO #3379] Signed-off-by: Chen Qi --- meta/recipes-core/busybox/busybox.inc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc index 972e7d0..6ed5e09 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -37,6 +37,8 @@ RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc" inherit cml1 update-rc.d +do_config[depends] = "kern-tools-native:do_populate_sysroot" + # internal helper def busybox_cfg(feature, features, tokens, cnf, rem): if type(tokens) == type(""): @@ -112,8 +114,19 @@ 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 + do_configure () { do_prepare_config + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} cml1_do_configure } -- 1.7.9.5 --------------050105040600050402060206--