| Submitter | Qi.Chen@windriver.com |
|---|---|
| Date | Feb. 5, 2013, 6:42 a.m. |
| Message ID | <5110A9D1.20208@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/44053/ |
| State | New |
| Headers | show |
Comments
On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote: > 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? > Yep, this is enough for now. It re-uses the significant part of the infrastructure, which is the important part. Once it is in tree, I can refine the dependency and some other minor modifications. Feel free to add my Signed-off-by: to the patch as well. Cheers, Bruce > If so, I'll send out the patch. > > Thanks, > Chen Qi >
On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote: > On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote: > 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: > > <mailto:Qi.Chen@windriver.com>> > > 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? > > Yep, this is enough for now. It re-uses the significant part of the > infrastructure, which > is the important part. Once it is in tree, I can refine the dependency > and some other > minor modifications. > > Feel free to add my Signed-off-by: to the patch as well. This patch triggers a failure on the autobuilder: http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio (its reproducible, this is the second one now) I suspect there is a missing DEPENDS += "kern-tools-native". You'd be able to reproduce this with a: bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c clean; bitbake busybox Cheers, Richard
On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote: >> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote: >> 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: >> > <mailto:Qi.Chen@windriver.com>> >> > 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? >> >> Yep, this is enough for now. It re-uses the significant part of the >> infrastructure, which >> is the important part. Once it is in tree, I can refine the dependency >> and some other >> minor modifications. >> >> Feel free to add my Signed-off-by: to the patch as well. > > This patch triggers a failure on the autobuilder: Hmmm. I didn't realize this had been picked up yet, I was waiting for a repost with the Sign-offs. I assume this is master under test ? I can pick up the patch from there and send an updated patch, since Chen Qi won't be around to look into this for a few days. Cheers, Bruce > > http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio > > (its reproducible, this is the second one now) > > I suspect there is a missing DEPENDS += "kern-tools-native". > > You'd be able to reproduce this with a: > > bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c clean; bitbake busybox > > Cheers, > > Richard > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote: > On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote: > >> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote: > >> 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: > >> > <mailto:Qi.Chen@windriver.com>> > >> > 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? > >> > >> Yep, this is enough for now. It re-uses the significant part of the > >> infrastructure, which > >> is the important part. Once it is in tree, I can refine the dependency > >> and some other > >> minor modifications. > >> > >> Feel free to add my Signed-off-by: to the patch as well. > > > > This patch triggers a failure on the autobuilder: > > Hmmm. I didn't realize this had been picked up yet, I was waiting for > a repost with the Sign-offs. I assume this is master under test ? I can > pick up the patch from there and send an updated patch, since Chen Qi > won't be around to look into this for a few days. It was master under test, it won't make master until it works :) I don't mind who sends me the working version. Cheers, Richard
On Tue, Feb 12, 2013 at 10:32 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote: >> On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie >> <richard.purdie@linuxfoundation.org> wrote: >> > On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote: >> >> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote: >> >> 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: >> >> > <mailto:Qi.Chen@windriver.com>> >> >> > 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? >> >> >> >> Yep, this is enough for now. It re-uses the significant part of the >> >> infrastructure, which >> >> is the important part. Once it is in tree, I can refine the dependency >> >> and some other >> >> minor modifications. >> >> >> >> Feel free to add my Signed-off-by: to the patch as well. >> > >> > This patch triggers a failure on the autobuilder: >> >> Hmmm. I didn't realize this had been picked up yet, I was waiting for >> a repost with the Sign-offs. I assume this is master under test ? I can >> pick up the patch from there and send an updated patch, since Chen Qi >> won't be around to look into this for a few days. > > It was master under test, it won't make master until it works :) > > I don't mind who sends me the working version. Attached is the fixed up patch with DEPENDS, the existing one had a typo in: do_config[depends] = "kern-tools-native:do_populate_sysroot" I've gone ahead and replaced it with a DEPENDS and tested the failure case here. This is a complete patch replacement, let me know if you'd prefer something incremental. Cheers, Bruce > > Cheers, > > Richard > > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
On Tue, 2013-02-12 at 11:50 -0500, Bruce Ashfield wrote: > Attached is the fixed up patch with DEPENDS, the existing one had a typo > in: > > do_config[depends] = "kern-tools-native:do_populate_sysroot" > > I've gone ahead and replaced it with a DEPENDS and tested the failure case > here. > > This is a complete patch replacement, let me know if you'd prefer something > incremental. DEPENDS should be towards the start of the file and/or use =+ in case something in one of the classes also sets DEPENDS. I tweaked and merged it since I don't really want to review it again ;-). Cheers, Richard
On Wed, Feb 13, 2013 at 11:53 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-02-12 at 11:50 -0500, Bruce Ashfield wrote: >> Attached is the fixed up patch with DEPENDS, the existing one had a typo >> in: >> >> do_config[depends] = "kern-tools-native:do_populate_sysroot" >> >> I've gone ahead and replaced it with a DEPENDS and tested the failure case >> here. >> >> This is a complete patch replacement, let me know if you'd prefer something >> incremental. > > DEPENDS should be towards the start of the file and/or use =+ in case > something in one of the classes also sets DEPENDS. I tweaked and merged > it since I don't really want to review it again ;-). Sounds good, thanks for the += addition, as for the location, I just put it right over the spot of the old dependency, since it wasn't going out of my way to clean parts not related to the immediate fix :) Cheers, Bruce > > Cheers, > > Richard >
Patch
From a9d36bf24f349f046e9b65ccf4af3352c4dedabf Mon Sep 17 00:00:00 2001 From: Chen Qi <Qi.Chen@windriver.com> 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 <Qi.Chen@windriver.com> --- 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