Patchwork [1/1] busybox: add config fragments

login
register
mail settings
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

Qi.Chen@windriver.com - Feb. 5, 2013, 6:42 a.m.
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!
>
>
>     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
Bruce Ashfield - Feb. 5, 2013, 4:29 p.m.
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
>
Richard Purdie - Feb. 12, 2013, 1:21 p.m.
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
Bruce Ashfield - Feb. 12, 2013, 2:06 p.m.
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"
Richard Purdie - Feb. 12, 2013, 3:32 p.m.
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
Bruce Ashfield - Feb. 12, 2013, 4:50 p.m.
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"
Richard Purdie - Feb. 13, 2013, 4:53 p.m.
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
Bruce Ashfield - Feb. 13, 2013, 4:59 p.m.
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