* [PATCH 0/1] busybox: add config fragments
@ 2013-02-01 9:00 Qi.Chen
2013-02-01 9:00 ` [PATCH 1/1] " Qi.Chen
0 siblings, 1 reply; 14+ messages in thread
From: Qi.Chen @ 2013-02-01 9:00 UTC (permalink / raw)
To: openembedded-core; +Cc: Zhenfeng.Zhao
From: Chen Qi <Qi.Chen@windriver.com>
Test Cases
----------
1. Backward Compatibility
Operation:
No config fragments, build busybox
Expected Result:
Everything should be the same with before, especially the .config file
[Actual Result (Success/Fail): Success]
2. Single config fragment: enable a utility
Operation:
Add a config fragment which enables hostid functionality and build core-image-minimal
Expected Result:
hostid command on target could work
[Actual Result (Success/Fail): Success]
3. Multiple config fragments: enable utilities
Followed by test case 2, add a config fragment which enables cal and build minimal image
Expected Result:
cal command on target could work
[Actual Result (Success/Fail): Success]
4. Mutliple config fragments: enable some utilities and disable some utilities
Operation:
Followed by test case 3, add a config fragment which disables and build minimal image
Expected Result:
vi command on target could not work
[Actual Result (Success/Fail): Success]
The following changes since commit 9a26b9c69c47c87ce71a06f76682c187767e7897:
rpm: Ensure native binaries are correctly wrapped (2013-01-30 14:47:30 +0000)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/busybox-config-fragments
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/busybox-config-fragments
Chen Qi (1):
busybox: add config fragments
meta/recipes-core/busybox/busybox.inc | 45 +++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
--
1.7.9.5
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/1] busybox: add config fragments
2013-02-01 9:00 [PATCH 0/1] busybox: add config fragments Qi.Chen
@ 2013-02-01 9:00 ` Qi.Chen
2013-02-01 14:18 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Qi.Chen @ 2013-02-01 9:00 UTC (permalink / raw)
To: openembedded-core; +Cc: Zhenfeng.Zhao
From: Chen Qi <Qi.Chen@windriver.com>
Add config fragments to busybox.
Both the implementation and the use case are similar to yocto kernel's
configuration fragments.
[YOCTO #3379]
Signed-off-by: Chen Qi <Qi.Chen@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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-01 9:00 ` [PATCH 1/1] " Qi.Chen
@ 2013-02-01 14:18 ` Bruce Ashfield
2013-02-01 18:56 ` Saul Wold
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-01 14:18 UTC (permalink / raw)
To: Qi.Chen; +Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3888 bytes --]
On Fri, Feb 1, 2013 at 4:00 AM, <Qi.Chen@windriver.com> wrote:
> From: Chen Qi <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.
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@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@lists.openembedded.org
> 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"
[-- Attachment #2: Type: text/html, Size: 5142 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-01 14:18 ` Bruce Ashfield
@ 2013-02-01 18:56 ` Saul Wold
2013-02-01 19:08 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Saul Wold @ 2013-02-01 18:56 UTC (permalink / raw)
To: Bruce Ashfield
Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
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?
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?
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@windriver.com
> <mailto:Qi.Chen@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@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-01 18:56 ` Saul Wold
@ 2013-02-01 19:08 ` Bruce Ashfield
2013-02-05 3:01 ` ChenQi
2013-02-05 6:42 ` ChenQi
0 siblings, 2 replies; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-01 19:08 UTC (permalink / raw)
To: Saul Wold; +Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 6783 bytes --]
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
>
> 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@windriver.com
>> <mailto:Qi.Chen@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@lists.**openembedded.org<Openembedded-core@lists.openembedded.org>
>> <mailto:Openembedded-core@**lists.openembedded.org<Openembedded-core@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@lists.**openembedded.org<Openembedded-core@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"
[-- Attachment #2: Type: text/html, Size: 9093 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-01 19:08 ` Bruce Ashfield
@ 2013-02-05 3:01 ` ChenQi
2013-02-05 6:42 ` ChenQi
1 sibling, 0 replies; 14+ messages in thread
From: ChenQi @ 2013-02-05 3:01 UTC (permalink / raw)
To: Bruce Ashfield
Cc: and discussions about the oe-core layer, Patches, Zhenfeng.Zhao
[-- Attachment #1: Type: text/plain, Size: 7829 bytes --]
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!
I thought about keeping the codes in sync but couldn't figure out a nice
way.
It would be great if you do so.
Thanks in advance :)
Best Regards,
Chen Qi
>
> 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@windriver.com
> <mailto:Qi.Chen@windriver.com>
> <mailto:Qi.Chen@windriver.com
> <mailto:Qi.Chen@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@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> <mailto:Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>>
>
> 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@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> 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"
[-- Attachment #2: Type: text/html, Size: 18185 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-01 19:08 ` Bruce Ashfield
2013-02-05 3:01 ` ChenQi
@ 2013-02-05 6:42 ` ChenQi
2013-02-05 16:29 ` Bruce Ashfield
1 sibling, 1 reply; 14+ messages in thread
From: ChenQi @ 2013-02-05 6:42 UTC (permalink / raw)
To: Bruce Ashfield
Cc: and discussions about the oe-core layer, Patches, Zhenfeng.Zhao
[-- Attachment #1.1: Type: text/plain, Size: 3084 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 6518 bytes --]
[-- Attachment #2: 0001-busybox-add-config-fragments.patch --]
[-- Type: text/x-patch, Size: 1511 bytes --]
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-05 6:42 ` ChenQi
@ 2013-02-05 16:29 ` Bruce Ashfield
2013-02-12 13:21 ` Richard Purdie
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-05 16:29 UTC (permalink / raw)
To: ChenQi; +Cc: Patches and discussions about the oe-core layer, Zhenfeng.Zhao
[-- Attachment #1: Type: text/plain, Size: 3252 bytes --]
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
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 6862 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-05 16:29 ` Bruce Ashfield
@ 2013-02-12 13:21 ` Richard Purdie
2013-02-12 14:06 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2013-02-12 13:21 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Zhenfeng.Zhao, Patches, oe-core layer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-12 13:21 ` Richard Purdie
@ 2013-02-12 14:06 ` Bruce Ashfield
2013-02-12 15:32 ` Richard Purdie
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-12 14:06 UTC (permalink / raw)
To: Richard Purdie
Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
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"
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-12 14:06 ` Bruce Ashfield
@ 2013-02-12 15:32 ` Richard Purdie
2013-02-12 16:50 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2013-02-12 15:32 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Zhenfeng.Zhao, Patches, oe-core layer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-12 15:32 ` Richard Purdie
@ 2013-02-12 16:50 ` Bruce Ashfield
2013-02-13 16:53 ` Richard Purdie
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-12 16:50 UTC (permalink / raw)
To: Richard Purdie
Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]
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"
[-- Attachment #2: 0001-busybox-add-config-fragments.patch --]
[-- Type: application/octet-stream, Size: 1656 bytes --]
From 1dc48ba9872afc12d822c3c399b4bd4af042d07c 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.
We also add kern-tools-native to busybox's DEPENDS variable to ensure
that merge_config.sh is available when required.
[YOCTO #3379]
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.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..b656a92 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
+DEPENDS = "kern-tools-native"
+
# 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.10.4
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-12 16:50 ` Bruce Ashfield
@ 2013-02-13 16:53 ` Richard Purdie
2013-02-13 16:59 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2013-02-13 16:53 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Zhenfeng.Zhao, Patches, oe-core layer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] busybox: add config fragments
2013-02-13 16:53 ` Richard Purdie
@ 2013-02-13 16:59 ` Bruce Ashfield
0 siblings, 0 replies; 14+ messages in thread
From: Bruce Ashfield @ 2013-02-13 16:59 UTC (permalink / raw)
To: Richard Purdie
Cc: Zhenfeng.Zhao, Patches and discussions about the oe-core layer
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
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-02-13 17:15 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-01 9:00 [PATCH 0/1] busybox: add config fragments Qi.Chen
2013-02-01 9:00 ` [PATCH 1/1] " Qi.Chen
2013-02-01 14:18 ` Bruce Ashfield
2013-02-01 18:56 ` Saul Wold
2013-02-01 19:08 ` Bruce Ashfield
2013-02-05 3:01 ` ChenQi
2013-02-05 6:42 ` ChenQi
2013-02-05 16:29 ` Bruce Ashfield
2013-02-12 13:21 ` Richard Purdie
2013-02-12 14:06 ` Bruce Ashfield
2013-02-12 15:32 ` Richard Purdie
2013-02-12 16:50 ` Bruce Ashfield
2013-02-13 16:53 ` Richard Purdie
2013-02-13 16:59 ` Bruce Ashfield
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.