[OE-core] [PATCH 1/1] busybox: add config fragments
Bruce Ashfield
bruce.ashfield at gmail.com
Fri Feb 1 19:08:28 UTC 2013
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
>
> 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 at windriver.com
>> <mailto:Qi.Chen at 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 at lists.**openembedded.org<Openembedded-core at lists.openembedded.org>
>> <mailto:Openembedded-core@**lists.openembedded.org<Openembedded-core at lists.openembedded.org>
>> >
>>
>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>> openembedded-core<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 at lists.**openembedded.org<Openembedded-core at lists.openembedded.org>
>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130201/b7a22d92/attachment-0002.html>
More information about the Openembedded-core
mailing list