[OE-core] [PATCH 1/1] busybox: add config fragments

[Bruce Ashfield]

On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen at 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 at 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 at windriver.com
>>>  <mailto:Qi.Chen at windriver.com>> wrote:
>>>
>>>     From: Chen Qi <Qi.Chen at windriver.com <mailto:Qi.Chen at 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
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130205/6b24c246/attachment-0002.html>