* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-01-29 13:10 ` Alexandre Belloni
@ 2014-01-29 15:03 ` Bruce Ashfield
2014-02-06 13:48 ` Bruce Ashfield
2014-02-06 21:48 ` Bruce Ashfield
2 siblings, 0 replies; 20+ messages in thread
From: Bruce Ashfield @ 2014-01-29 15:03 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: darren.hart, Darren Hart, openembedded-core
On 14-01-29 08:10 AM, Alexandre Belloni wrote:
> Hi Bruce,
>
> Any news on that ?
Sorry, I hadn't intended for this to sit with no reply for this lenght
of time. I was tied up working with 3.13 and 3.14 yocto kerenls. I'm
now in a position to run some migration tests and will follow up with
the results asap.
Bruce
>
> On Tue, Jan 07, 2014 at 15:39:01 -0500, Bruce Ashfield wrote :
>> On 14-01-07 03:27 PM, Alexandre Belloni wrote:
>>> On 07/01/2014 16:32, Bruce Ashfield wrote:
>>>> On 14-01-07 09:18 AM, Alexandre Belloni wrote:
>>>>> When using a defconfig, using yes '' | make oldconfig may not result in
>>>>> the correct configuration being set. For example:
>>>>>
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>> $ make savedefconfig
>>>>> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ yes '' | make oldconfig
>>>>> [...]
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=m
>>>>> CONFIG_USB_ETH_RNDIS=yThe enhancements in this release in comparison to previous releases are:
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> Using make olddefconfig solves that but we'll use oldnoconfig for
>>>>> backward compatibility with older kernels.
>>>>>
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ make oldnoconfig
>>>>> scripts/kconfig/conf --olddefconfig Kconfig
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> For more information, please refer to:
>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbe98bb9ed3dae23e320c6b113e35f129538d14a
>>>>>
>>>>
>>>> It was my understanding that this commit changed the Kconfig behaviour
>>>> to set the selected options to =y and prevent the menu choice from
>>>> "hiding" the options in a depedent choice menu. But maybe I'm remembering
>>>> wrong.
>>>>
>>>> The point being, that with that commit in place. Doesn't the behaviour
>>>> match what we want with yes and oldconfig ?
>>>>
>>>
>>> Nope, that commit is fixing the issue when using make <target>_defconfig
>>> or make olddefconfig. Note that using make menuconfig already had the
>>> correct behavior before that commit.
>>
>> right. I'm pretty familiar with that code, so I knew this worked.
>>
>>>
>>> As shown in my commit log, using yes '' | make oldconfig is still
>>> getting it wrong.
>>
>> But that was also my point. Since the target suggested in this
>> patch hasn't always existed (and hence has a kernel version binding),
>> why not use olddefconfig with this patch, and leave the functionality
>> closer to its existing behaviour ? We'd still have a kernel capability
>> binding, but we'd not have the =y converted to =m, and the default of
>> 'y' for new functionality would be maintained.
>>
>>>
>>>> .. I'll run some tests to confirm for myself, but I thought I'd throw
>>>> the question out as well. I don't typically use defconfigs, so I need
>>>> to do a bit of leg work.
>>>>
>>>
>>> Yeah, using a full .config doesn't trigger that behavior.
>>
>> I don't use those either :) but the end result is the same.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>> I don't have any big issues with the patch, but I just want to be sure,
>>>> since changing this default could change the configs of many defconfig
>>>> users, and they may have been unknowingly relying on the old behaviour.
>>>>
>>>
>>> I can understand that. But I don't see any other way to make the really
>>> expected behavior to work without risking breaking anything.
>>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-01-29 13:10 ` Alexandre Belloni
2014-01-29 15:03 ` Bruce Ashfield
@ 2014-02-06 13:48 ` Bruce Ashfield
2014-02-06 21:48 ` Bruce Ashfield
2 siblings, 0 replies; 20+ messages in thread
From: Bruce Ashfield @ 2014-02-06 13:48 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: darren.hart, Darren Hart, openembedded-core
On 14-01-29 08:10 AM, Alexandre Belloni wrote:
> Hi Bruce,
>
> Any news on that ?
And a update. I've been debugging some results that don't look
right, so I have haven't followed up yet.
I'm hopeful to get a consistent set of results by the end of
the day.
Bruce
>
> On Tue, Jan 07, 2014 at 15:39:01 -0500, Bruce Ashfield wrote :
>> On 14-01-07 03:27 PM, Alexandre Belloni wrote:
>>> On 07/01/2014 16:32, Bruce Ashfield wrote:
>>>> On 14-01-07 09:18 AM, Alexandre Belloni wrote:
>>>>> When using a defconfig, using yes '' | make oldconfig may not result in
>>>>> the correct configuration being set. For example:
>>>>>
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>> $ make savedefconfig
>>>>> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ yes '' | make oldconfig
>>>>> [...]
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=m
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> Using make olddefconfig solves that but we'll use oldnoconfig for
>>>>> backward compatibility with older kernels.
>>>>>
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ make oldnoconfig
>>>>> scripts/kconfig/conf --olddefconfig Kconfig
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> For more information, please refer to:
>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbe98bb9ed3dae23e320c6b113e35f129538d14a
>>>>>
>>>>
>>>> It was my understanding that this commit changed the Kconfig behaviour
>>>> to set the selected options to =y and prevent the menu choice from
>>>> "hiding" the options in a depedent choice menu. But maybe I'm remembering
>>>> wrong.
>>>>
>>>> The point being, that with that commit in place. Doesn't the behaviour
>>>> match what we want with yes and oldconfig ?
>>>>
>>>
>>> Nope, that commit is fixing the issue when using make <target>_defconfig
>>> or make olddefconfig. Note that using make menuconfig already had the
>>> correct behavior before that commit.
>>
>> right. I'm pretty familiar with that code, so I knew this worked.
>>
>>>
>>> As shown in my commit log, using yes '' | make oldconfig is still
>>> getting it wrong.
>>
>> But that was also my point. Since the target suggested in this
>> patch hasn't always existed (and hence has a kernel version binding),
>> why not use olddefconfig with this patch, and leave the functionality
>> closer to its existing behaviour ? We'd still have a kernel capability
>> binding, but we'd not have the =y converted to =m, and the default of
>> 'y' for new functionality would be maintained.
>>
>>>
>>>> .. I'll run some tests to confirm for myself, but I thought I'd throw
>>>> the question out as well. I don't typically use defconfigs, so I need
>>>> to do a bit of leg work.
>>>>
>>>
>>> Yeah, using a full .config doesn't trigger that behavior.
>>
>> I don't use those either :) but the end result is the same.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>> I don't have any big issues with the patch, but I just want to be sure,
>>>> since changing this default could change the configs of many defconfig
>>>> users, and they may have been unknowingly relying on the old behaviour.
>>>>
>>>
>>> I can understand that. But I don't see any other way to make the really
>>> expected behavior to work without risking breaking anything.
>>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-01-29 13:10 ` Alexandre Belloni
2014-01-29 15:03 ` Bruce Ashfield
2014-02-06 13:48 ` Bruce Ashfield
@ 2014-02-06 21:48 ` Bruce Ashfield
2014-02-07 14:02 ` Alexandre Belloni
2 siblings, 1 reply; 20+ messages in thread
From: Bruce Ashfield @ 2014-02-06 21:48 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: darren.hart, Darren Hart, openembedded-core
On 14-01-29 08:10 AM, Alexandre Belloni wrote:
> Hi Bruce,
>
> Any news on that ?
work with me on the triple nesting of this response, but it should be
easier to just reply to this email, and consolidate all the questions
I had.
This is also a bit long .. so apologies for that as well.
I've been running migration tests with the 3.14 yocto kernel I'm pulling
together, and not seeing the same behaviour that I expected, or what is
in your commit log. Are there any steps missing from what made the log ?
See below .. make sure to read to the bottom, since this is all largely
a discussion about the log in the end :)
> git branch --contains fbe98bb9ed3dae23e320c6b113e35f129538d14a
* master
> grep -C 2 ^VERSION Makefile
VERSION = 3
PATCHLEVEL = 14
SUBLEVEL = 0
So we have all the relevant commits, and a up to date tree. Operating
on the .config from a 64 bit x86 build:
> grep USB_ETH .config
CONFIG_USB_ETH=y
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
> make savedefconfig
scripts/kconfig/conf --savedefconfig=defconfig Kconfig
.config:5333:warning: override: USB_ETH changes choice state
.config:5336:warning: USB_G_NCM creates inconsistent choice state
.config:5337:warning: USB_GADGETFS creates inconsistent choice state
.config:5338:warning: USB_FUNCTIONFS creates inconsistent choice state
.config:5342:warning: USB_MASS_STORAGE creates inconsistent choice state
.config:5343:warning: USB_GADGET_TARGET creates inconsistent choice state
.config:5344:warning: USB_G_SERIAL creates inconsistent choice state
.config:5345:warning: USB_MIDI_GADGET creates inconsistent choice state
.config:5346:warning: USB_G_PRINTER creates inconsistent choice state
.config:5347:warning: USB_CDC_COMPOSITE creates inconsistent choice state
.config:5348:warning: USB_G_NOKIA creates inconsistent choice state
.config:5349:warning: USB_G_ACM_MS creates inconsistent choice state
.config:5351:warning: USB_G_HID creates inconsistent choice state
.config:5352:warning: USB_G_DBGP creates inconsistent choice state
.config:5355:warning: USB_G_WEBCAM creates inconsistent choice state
.config:6201:warning: symbol value 'm' invalid for VME_BUS
> cp defconfig .config
> yes '' | make oldconfig
> grep USB_ETH .config
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
So far so good, this matches what I'd expect. Now with olddefconfig /
oldnoconfig
> cp defconfig .config
> make oldnoconfig
scripts/kconfig/conf --olddefconfig Kconfig
#
# configuration written to .config
#
yow-bashfiel-d3 [/home/bruc...rnel/linux]> grep USB_ETH .config
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
.. CONFIG_USB_ETH is still =m.
I've also been running a whole series of configuration tests on the
defconfigs found in the various arch/platforms in the mainline kernel,
and on a modern (3.14-rc) kernel, getting the same results from
yes "" | oldconfig and olddefconfig. i.e. migrating their configs with
either technique results in the same resulting .config,
Which if you recall the above question was my big concern, was the
migration between kernel versions using the different techniques going
to yield different results on the same .config.
The answer to that is "it appears not", and really, taking a Kconfig's
default IS the right thing to do if you must make a choice, and aren't
familiar with the option.
** So, that leaves me with agreeing that the change should be ok from
that front, and that we definitely need the fallback to the yes "" |
oldconfig variant if the newer targets don't exist. But from my tests,
the commit log is slightly off .. again, maybe I messed something up
in my tests with 3.14, but it is worth double checking.
And finally, to allow someone who really doesn't like the command full
flexibility, I'm running with the following change, and it offers
an easy way to change behaviour .. opinions ?
--->----->--->----->--->----->--->----->
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b76a65699755..9510996d52c1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -313,6 +313,8 @@ python sysroot_stage_all () {
oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"),
d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}"))
}
+KERNEL_CONFIG_COMMAND ?= "yes '' | oe_runmake oldconfig"
+
kernel_do_configure() {
# fixes extra + in /lib/modules/2.6.37+
# $ scripts/setlocalversion . => +
@@ -325,7 +327,7 @@ kernel_do_configure() {
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi
- yes '' | oe_runmake oldconfig
+ eval ${KERNEL_CONFIG_COMMAND}
}
--->----->--->----->--->----->--->----->
Doing a v3 of the fallback version, with a checked commit log and
perhaps even the command flexibility would keep everyone happy and
I can add my Acked-by to that version.
Cheers,
Bruce
>
> On Tue, Jan 07, 2014 at 15:39:01 -0500, Bruce Ashfield wrote :
>> On 14-01-07 03:27 PM, Alexandre Belloni wrote:
>>> On 07/01/2014 16:32, Bruce Ashfield wrote:
>>>> On 14-01-07 09:18 AM, Alexandre Belloni wrote:
>>>>> When using a defconfig, using yes '' | make oldconfig may not result in
>>>>> the correct configuration being set. For example:
>>>>>
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>> $ make savedefconfig
>>>>> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ yes '' | make oldconfig
>>>>> [...]
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=m
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> Using make olddefconfig solves that but we'll use oldnoconfig for
>>>>> backward compatibility with older kernels.
>>>>>
>>>>> $ cp defconfig .config
>>>>> ‘defconfig’ -> ‘.config’
>>>>> $ make oldnoconfig
>>>>> scripts/kconfig/conf --olddefconfig Kconfig
>>>>> #
>>>>> # configuration written to .config
>>>>> #
>>>>> $ grep USB_ETH .config
>>>>> CONFIG_USB_ETH=y
>>>>> CONFIG_USB_ETH_RNDIS=y
>>>>> CONFIG_USB_ETH_EEM=y
>>>>>
>>>>> For more information, please refer to:
>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fbe98bb9ed3dae23e320c6b113e35f129538d14a
>>>>>
>>>>
>>>> It was my understanding that this commit changed the Kconfig behaviour
>>>> to set the selected options to =y and prevent the menu choice from
>>>> "hiding" the options in a depedent choice menu. But maybe I'm remembering
>>>> wrong.
>>>>
>>>> The point being, that with that commit in place. Doesn't the behaviour
>>>> match what we want with yes and oldconfig ?
>>>>
>>>
>>> Nope, that commit is fixing the issue when using make <target>_defconfig
>>> or make olddefconfig. Note that using make menuconfig already had the
>>> correct behavior before that commit.
>>
>> right. I'm pretty familiar with that code, so I knew this worked.
>>
>>>
>>> As shown in my commit log, using yes '' | make oldconfig is still
>>> getting it wrong.
>>
>> But that was also my point. Since the target suggested in this
>> patch hasn't always existed (and hence has a kernel version binding),
>> why not use olddefconfig with this patch, and leave the functionality
>> closer to its existing behaviour ? We'd still have a kernel capability
>> binding, but we'd not have the =y converted to =m, and the default of
>> 'y' for new functionality would be maintained.
>>
>>>
>>>> .. I'll run some tests to confirm for myself, but I thought I'd throw
>>>> the question out as well. I don't typically use defconfigs, so I need
>>>> to do a bit of leg work.
>>>>
>>>
>>> Yeah, using a full .config doesn't trigger that behavior.
>>
>> I don't use those either :) but the end result is the same.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>> I don't have any big issues with the patch, but I just want to be sure,
>>>> since changing this default could change the configs of many defconfig
>>>> users, and they may have been unknowingly relying on the old behaviour.
>>>>
>>>
>>> I can understand that. But I don't see any other way to make the really
>>> expected behavior to work without risking breaking anything.
>>>
>>
>
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-02-06 21:48 ` Bruce Ashfield
@ 2014-02-07 14:02 ` Alexandre Belloni
2014-02-07 15:11 ` Bruce Ashfield
0 siblings, 1 reply; 20+ messages in thread
From: Alexandre Belloni @ 2014-02-07 14:02 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: darren.hart, Darren Hart, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]
Hi,
So, I did the same tests with an x86_64 config and an ARM config.
On 06/02/2014 at 16:48:52 -0500, Bruce Ashfield wrote :
> > git branch --contains fbe98bb9ed3dae23e320c6b113e35f129538d14a
> * master
>
> > grep -C 2 ^VERSION Makefile
> VERSION = 3
> PATCHLEVEL = 14
> SUBLEVEL = 0
>
I'm also on 3.14, commit 9343224bfd4be6a02e6ae0c0d66426c955c7d76e
> So we have all the relevant commits, and a up to date tree. Operating
> on the .config from a 64 bit x86 build:
>
> > grep USB_ETH .config
> CONFIG_USB_ETH=y
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
>
> > make savedefconfig
> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
> .config:5333:warning: override: USB_ETH changes choice state
> .config:5336:warning: USB_G_NCM creates inconsistent choice state
> .config:5337:warning: USB_GADGETFS creates inconsistent choice state
> .config:5338:warning: USB_FUNCTIONFS creates inconsistent choice state
> .config:5342:warning: USB_MASS_STORAGE creates inconsistent choice state
> .config:5343:warning: USB_GADGET_TARGET creates inconsistent choice state
> .config:5344:warning: USB_G_SERIAL creates inconsistent choice state
> .config:5345:warning: USB_MIDI_GADGET creates inconsistent choice state
> .config:5346:warning: USB_G_PRINTER creates inconsistent choice state
> .config:5347:warning: USB_CDC_COMPOSITE creates inconsistent choice state
> .config:5348:warning: USB_G_NOKIA creates inconsistent choice state
> .config:5349:warning: USB_G_ACM_MS creates inconsistent choice state
> .config:5351:warning: USB_G_HID creates inconsistent choice state
> .config:5352:warning: USB_G_DBGP creates inconsistent choice state
> .config:5355:warning: USB_G_WEBCAM creates inconsistent choice state
> .config:6201:warning: symbol value 'm' invalid for VME_BUS
>
I don't get those warnings.
> > cp defconfig .config
>
> > yes '' | make oldconfig
>
> > grep USB_ETH .config
> CONFIG_USB_ETH=m
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
>
> So far so good, this matches what I'd expect. Now with olddefconfig
> / oldnoconfig
>
Exactly what I have and what I'm trying to fix.
> > cp defconfig .config
> > make oldnoconfig
> scripts/kconfig/conf --olddefconfig Kconfig
> #
> # configuration written to .config
> #
> yow-bashfiel-d3 [/home/bruc...rnel/linux]> grep USB_ETH .config
> CONFIG_USB_ETH=m
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
>
> .. CONFIG_USB_ETH is still =m.
>
That is where I end up with:
$ grep USB_ETH .config
CONFIG_USB_ETH=y
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
> I've also been running a whole series of configuration tests on the
> defconfigs found in the various arch/platforms in the mainline kernel,
> and on a modern (3.14-rc) kernel, getting the same results from
> yes "" | oldconfig and olddefconfig. i.e. migrating their configs with
> either technique results in the same resulting .config,
>
> Which if you recall the above question was my big concern, was the
> migration between kernel versions using the different techniques going
> to yield different results on the same .config.
>
> The answer to that is "it appears not", and really, taking a Kconfig's
> default IS the right thing to do if you must make a choice, and aren't
> familiar with the option.
>
But it should be different because using 'yes "" | oldconfig' is wrong.
Let's have a look at qi_lb60_defconfig:
$ ARCH=mips make qi_lb60_defconfig
#
# configuration written to .config
#
$ grep USB_ETH .config
CONFIG_USB_ETH=y
# CONFIG_USB_ETH_RNDIS is not set
# CONFIG_USB_ETH_EEM is not set
$ cp arch/mips/configs/qi_lb60_defconfig .config
‘arch/mips/configs/qi_lb60_defconfig’ -> ‘.config’
$ yes '' | make oldconfig
[...]
$ grep USB_ETH .config
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
# CONFIG_USB_ETH_EEM is not set
> ** So, that leaves me with agreeing that the change should be ok from
> that front, and that we definitely need the fallback to the yes "" |
> oldconfig variant if the newer targets don't exist. But from my tests,
> the commit log is slightly off .. again, maybe I messed something up
> in my tests with 3.14, but it is worth double checking.
>
I believe my commit message is actually right and something went wrong
in your tests.
> And finally, to allow someone who really doesn't like the command full
> flexibility, I'm running with the following change, and it offers
> an easy way to change behaviour .. opinions ?
>
> --->----->--->----->--->----->--->----->
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index b76a65699755..9510996d52c1 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -313,6 +313,8 @@ python sysroot_stage_all () {
> oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"),
> d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}"))
> }
>
> +KERNEL_CONFIG_COMMAND ?= "yes '' | oe_runmake oldconfig"
> +
If we go that route, shouldn't we have sane default and use
KERNEL_CONFIG_COMMAND ?= "oe_runmake oldnoconfig || yes '' | oe_runmake oldconfig"
I understand that it may change the behaviour for some existing
configurations but I believe it is the correct behaviour to actually
respect what is in the kernel config provided by the user.
> kernel_do_configure() {
> # fixes extra + in /lib/modules/2.6.37+
> # $ scripts/setlocalversion . => +
> @@ -325,7 +327,7 @@ kernel_do_configure() {
> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
> - yes '' | oe_runmake oldconfig
> + eval ${KERNEL_CONFIG_COMMAND}
> }
> --->----->--->----->--->----->--->----->
>
> Doing a v3 of the fallback version, with a checked commit log and
> perhaps even the command flexibility would keep everyone happy and
> I can add my Acked-by to that version.
>
BTW, I've been told by the kconfig maintainers that the preferred way of
doing it would be to copy the provided defconfig to
arch/${ARCH}/configs/oe_defconfig and then oe_runmake oe_defconfig. But
unfortunately, that doesn't work for architectures without a 'configs'
directory. For 3.14, this is only alpha and frv but x86 got it starting
with 2266cfd50de3872e877eeca3dd4a6f940f22ba60, this is v2.6.24 and I
remember being asked to support older kernels.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-02-07 14:02 ` Alexandre Belloni
@ 2014-02-07 15:11 ` Bruce Ashfield
2014-02-07 15:43 ` Alexandre Belloni
0 siblings, 1 reply; 20+ messages in thread
From: Bruce Ashfield @ 2014-02-07 15:11 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: darren.hart, Darren Hart, openembedded-core
On 14-02-07 09:02 AM, Alexandre Belloni wrote:
> Hi,
>
> So, I did the same tests with an x86_64 config and an ARM config.
>
> On 06/02/2014 at 16:48:52 -0500, Bruce Ashfield wrote :
>>> git branch --contains fbe98bb9ed3dae23e320c6b113e35f129538d14a
>> * master
>>
>>> grep -C 2 ^VERSION Makefile
>> VERSION = 3
>> PATCHLEVEL = 14
>> SUBLEVEL = 0
>>
>
> I'm also on 3.14, commit 9343224bfd4be6a02e6ae0c0d66426c955c7d76e
>
>> So we have all the relevant commits, and a up to date tree. Operating
>> on the .config from a 64 bit x86 build:
>>
>>> grep USB_ETH .config
>> CONFIG_USB_ETH=y
>> CONFIG_USB_ETH_RNDIS=y
>> CONFIG_USB_ETH_EEM=y
>>
>>> make savedefconfig
>> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
>> .config:5333:warning: override: USB_ETH changes choice state
>> .config:5336:warning: USB_G_NCM creates inconsistent choice state
>> .config:5337:warning: USB_GADGETFS creates inconsistent choice state
>> .config:5338:warning: USB_FUNCTIONFS creates inconsistent choice state
>> .config:5342:warning: USB_MASS_STORAGE creates inconsistent choice state
>> .config:5343:warning: USB_GADGET_TARGET creates inconsistent choice state
>> .config:5344:warning: USB_G_SERIAL creates inconsistent choice state
>> .config:5345:warning: USB_MIDI_GADGET creates inconsistent choice state
>> .config:5346:warning: USB_G_PRINTER creates inconsistent choice state
>> .config:5347:warning: USB_CDC_COMPOSITE creates inconsistent choice state
>> .config:5348:warning: USB_G_NOKIA creates inconsistent choice state
>> .config:5349:warning: USB_G_ACM_MS creates inconsistent choice state
>> .config:5351:warning: USB_G_HID creates inconsistent choice state
>> .config:5352:warning: USB_G_DBGP creates inconsistent choice state
>> .config:5355:warning: USB_G_WEBCAM creates inconsistent choice state
>> .config:6201:warning: symbol value 'm' invalid for VME_BUS
>>
>
> I don't get those warnings.
The warnings are unimportant, they are because of the base config
that I used, and they are talking about how the default symbol processing
can be applied to a config when migrating kernels. Which is the point
I'm trying to make.
>
>>> cp defconfig .config
>>
>>> yes '' | make oldconfig
>>
>>> grep USB_ETH .config
>> CONFIG_USB_ETH=m
>> CONFIG_USB_ETH_RNDIS=y
>> CONFIG_USB_ETH_EEM=y
>>
>> So far so good, this matches what I'd expect. Now with olddefconfig
>> / oldnoconfig
>>
>
> Exactly what I have and what I'm trying to fix.
>
>>> cp defconfig .config
>>> make oldnoconfig
>> scripts/kconfig/conf --olddefconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> yow-bashfiel-d3 [/home/bruc...rnel/linux]> grep USB_ETH .config
>> CONFIG_USB_ETH=m
>> CONFIG_USB_ETH_RNDIS=y
>> CONFIG_USB_ETH_EEM=y
>>
>> .. CONFIG_USB_ETH is still =m.
>>
>
> That is where I end up with:
What's in your saved defconfig ? My point is that if you are saving
a defconfig, it is on the save where that value needs to be correct,
not on the application to the tree, since if it is set .. it will be
respected.
>
> $ grep USB_ETH .config
> CONFIG_USB_ETH=y
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
>
>> I've also been running a whole series of configuration tests on the
>> defconfigs found in the various arch/platforms in the mainline kernel,
>> and on a modern (3.14-rc) kernel, getting the same results from
>> yes "" | oldconfig and olddefconfig. i.e. migrating their configs with
>> either technique results in the same resulting .config,
>>
>> Which if you recall the above question was my big concern, was the
>> migration between kernel versions using the different techniques going
>> to yield different results on the same .config.
>>
>> The answer to that is "it appears not", and really, taking a Kconfig's
>> default IS the right thing to do if you must make a choice, and aren't
>> familiar with the option.
>>
>
> But it should be different because using 'yes "" | oldconfig' is wrong.
It isn't wrong .. it is just one way of processing a config. And
again to my point, one that may have been implicitly relied upon by
some use cases.
> Let's have a look at qi_lb60_defconfig:
>
> $ ARCH=mips make qi_lb60_defconfig
> #
> # configuration written to .config
> #
> $ grep USB_ETH .config
> CONFIG_USB_ETH=y
> # CONFIG_USB_ETH_RNDIS is not set
> # CONFIG_USB_ETH_EEM is not set
>
> $ cp arch/mips/configs/qi_lb60_defconfig .config
> ‘arch/mips/configs/qi_lb60_defconfig’ -> ‘.config’
> $ yes '' | make oldconfig
> [...]
> $ grep USB_ETH .config
> CONFIG_USB_ETH=m
> # CONFIG_USB_ETH_RNDIS is not set
> # CONFIG_USB_ETH_EEM is not set
This is a different use case, there's no save defconfig happening
between the copy and the run, which is what was happening in the
other one.
>
>
>> ** So, that leaves me with agreeing that the change should be ok from
>> that front, and that we definitely need the fallback to the yes "" |
>> oldconfig variant if the newer targets don't exist. But from my tests,
>> the commit log is slightly off .. again, maybe I messed something up
>> in my tests with 3.14, but it is worth double checking.
>>
>
> I believe my commit message is actually right and something went wrong
> in your tests.
Heh, then we are at a stalemate. I used a stock 3.14 kernel, and my
results stand, and in my testing, your results with the savedefconfig
flow don't match.
Use the mips example in the changelog then .. since that one actually
is a consistent result.
>
>> And finally, to allow someone who really doesn't like the command full
>> flexibility, I'm running with the following change, and it offers
>> an easy way to change behaviour .. opinions ?
>>
>> --->----->--->----->--->----->--->----->
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index b76a65699755..9510996d52c1 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -313,6 +313,8 @@ python sysroot_stage_all () {
>> oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"),
>> d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}"))
>> }
>>
>> +KERNEL_CONFIG_COMMAND ?= "yes '' | oe_runmake oldconfig"
>> +
>
> If we go that route, shouldn't we have sane default and use
> KERNEL_CONFIG_COMMAND ?= "oe_runmake oldnoconfig || yes '' | oe_runmake oldconfig"
Of course, that's what I was referencing when I said "the fallback",
I just didn't need it for my testing.
>
> I understand that it may change the behaviour for some existing
> configurations but I believe it is the correct behaviour to actually
> respect what is in the kernel config provided by the user.
On that point, I disagree. It is respecting the default values, not
the config provided by the user. If the user wants full control, they
can supply a full .config, or fragments.
>
>> kernel_do_configure() {
>> # fixes extra + in /lib/modules/2.6.37+
>> # $ scripts/setlocalversion . => +
>> @@ -325,7 +327,7 @@ kernel_do_configure() {
>> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>> cp "${WORKDIR}/defconfig" "${B}/.config"
>> fi
>> - yes '' | oe_runmake oldconfig
>> + eval ${KERNEL_CONFIG_COMMAND}
>> }
>> --->----->--->----->--->----->--->----->
>>
>> Doing a v3 of the fallback version, with a checked commit log and
>> perhaps even the command flexibility would keep everyone happy and
>> I can add my Acked-by to that version.
>>
>
> BTW, I've been told by the kconfig maintainers that the preferred way of
> doing it would be to copy the provided defconfig to
> arch/${ARCH}/configs/oe_defconfig and then oe_runmake oe_defconfig. But
linux-yocto* doesn't use defconfigs, and defconfigs can cause plenty of
pain, so opinions vary on this and anyone with a custom kernel recipe
is free to use defconfigs from within the tree, but making the generic
build change to that .. risks jiggling things for no obvious gain.
Cheers,
Bruce
> unfortunately, that doesn't work for architectures without a 'configs'
> directory. For 3.14, this is only alpha and frv but x86 got it starting
> with 2266cfd50de3872e877eeca3dd4a6f940f22ba60, this is v2.6.24 and I
> remember being asked to support older kernels.
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-02-07 15:11 ` Bruce Ashfield
@ 2014-02-07 15:43 ` Alexandre Belloni
2014-02-07 16:10 ` Bruce Ashfield
0 siblings, 1 reply; 20+ messages in thread
From: Alexandre Belloni @ 2014-02-07 15:43 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: darren.hart, Darren Hart, openembedded-core
On 07/02/2014 at 10:11:18 -0500, Bruce Ashfield wrote :
> On 14-02-07 09:02 AM, Alexandre Belloni wrote:
> >>>cp defconfig .config
> >>>make oldnoconfig
> >>scripts/kconfig/conf --olddefconfig Kconfig
> >>#
> >># configuration written to .config
> >>#
> >>yow-bashfiel-d3 [/home/bruc...rnel/linux]> grep USB_ETH .config
> >>CONFIG_USB_ETH=m
> >>CONFIG_USB_ETH_RNDIS=y
> >>CONFIG_USB_ETH_EEM=y
> >>
> >>.. CONFIG_USB_ETH is still =m.
> >>
> >
> >That is where I end up with:
>
> What's in your saved defconfig ? My point is that if you are saving
> a defconfig, it is on the save where that value needs to be correct,
> not on the application to the tree, since if it is set .. it will be
> respected.
>
Exactly my point, using yes "" | make oldconfig DOESN'T respect the
provided defconfig because that doesn't go through the correct kconfig
code that is solving the issue:
$ make savedefconfig
scripts/kconfig/conf --savedefconfig=defconfig Kconfig
$ grep USB_ETH defconfig
CONFIG_USB_ETH=y
CONFIG_USB_ETH_EEM=y
$ cp defconfig .config
‘defconfig’ -> ‘.config’
$ yes '' | make oldconfig > /dev/null
$ grep USB_ETH .config
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
$ cp defconfig .config
‘defconfig’ -> ‘.config’
$ make oldnoconfig
scripts/kconfig/conf --olddefconfig Kconfig
#
# configuration written to .config
#
$ grep USB_ETH .config
CONFIG_USB_ETH=y
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_ETH_EEM=y
> >I believe my commit message is actually right and something went wrong
> >in your tests.
>
> Heh, then we are at a stalemate. I used a stock 3.14 kernel, and my
> results stand, and in my testing, your results with the savedefconfig
> flow don't match.
>
Please check again, maybe you had CONFIG_USB_ETH=m in your defconfig ?
> Use the mips example in the changelog then .. since that one actually
> is a consistent result.
>
Ok, I can do that.
> >
> >I understand that it may change the behaviour for some existing
> >configurations but I believe it is the correct behaviour to actually
> >respect what is in the kernel config provided by the user.
>
> On that point, I disagree. It is respecting the default values, not
> the config provided by the user. If the user wants full control, they
> can supply a full .config, or fragments.
>
I'm not sure I follow you. I have a defconfig with CONFIG_USB_ETH=y and
I ended with a kernel compiled with CONFIG_USB_ETH=m. I don't think this
is sane. It would not be necessary to provide a full kernel .config if
the config options provided in the defconfig were respected.
> >
> >> kernel_do_configure() {
> >> # fixes extra + in /lib/modules/2.6.37+
> >> # $ scripts/setlocalversion . => +
> >>@@ -325,7 +327,7 @@ kernel_do_configure() {
> >> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> >> cp "${WORKDIR}/defconfig" "${B}/.config"
> >> fi
> >>- yes '' | oe_runmake oldconfig
> >>+ eval ${KERNEL_CONFIG_COMMAND}
> >> }
> >>--->----->--->----->--->----->--->----->
> >>
> >>Doing a v3 of the fallback version, with a checked commit log and
> >>perhaps even the command flexibility would keep everyone happy and
> >>I can add my Acked-by to that version.
> >>
> >
> >BTW, I've been told by the kconfig maintainers that the preferred way of
> >doing it would be to copy the provided defconfig to
> >arch/${ARCH}/configs/oe_defconfig and then oe_runmake oe_defconfig. But
>
> linux-yocto* doesn't use defconfigs, and defconfigs can cause plenty of
> pain, so opinions vary on this and anyone with a custom kernel recipe
> is free to use defconfigs from within the tree, but making the generic
> build change to that .. risks jiggling things for no obvious gain.
>
linux-yocto is not the only user of kernel.bbclass. meta-fsl-arm and
meta-fs-arm-extra are using defconfigs and Otavio would prefer not
having full configs which I understand (and isn't the name used by
kernel.bbclass "defconfig" misleading then ?).
Anyway, let me prepare a v3 and see if we all agree on that (and I
believe we will :) ).
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig
2014-02-07 15:43 ` Alexandre Belloni
@ 2014-02-07 16:10 ` Bruce Ashfield
0 siblings, 0 replies; 20+ messages in thread
From: Bruce Ashfield @ 2014-02-07 16:10 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: darren.hart, Darren Hart, openembedded-core
On 14-02-07 10:43 AM, Alexandre Belloni wrote:
> On 07/02/2014 at 10:11:18 -0500, Bruce Ashfield wrote :
>> On 14-02-07 09:02 AM, Alexandre Belloni wrote:
>>>>> cp defconfig .config
>>>>> make oldnoconfig
>>>> scripts/kconfig/conf --olddefconfig Kconfig
>>>> #
>>>> # configuration written to .config
>>>> #
>>>> yow-bashfiel-d3 [/home/bruc...rnel/linux]> grep USB_ETH .config
>>>> CONFIG_USB_ETH=m
>>>> CONFIG_USB_ETH_RNDIS=y
>>>> CONFIG_USB_ETH_EEM=y
>>>>
>>>> .. CONFIG_USB_ETH is still =m.
>>>>
>>>
>>> That is where I end up with:
>>
>> What's in your saved defconfig ? My point is that if you are saving
>> a defconfig, it is on the save where that value needs to be correct,
>> not on the application to the tree, since if it is set .. it will be
>> respected.
>>
>
> Exactly my point, using yes "" | make oldconfig DOESN'T respect the
> provided defconfig because that doesn't go through the correct kconfig
> code that is solving the issue:
>
> $ make savedefconfig
> scripts/kconfig/conf --savedefconfig=defconfig Kconfig
> $ grep USB_ETH defconfig
> CONFIG_USB_ETH=y
> CONFIG_USB_ETH_EEM=y
> $ cp defconfig .config
> ‘defconfig’ -> ‘.config’
> $ yes '' | make oldconfig > /dev/null
> $ grep USB_ETH .config
> CONFIG_USB_ETH=m
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
There are actually multiple workflows that can get this wrong .. or
right. So we are actually agreeing, it all just depends on how you
are handling the configs. savedefconfig can get do strange things
with the defaults as well:
> git describe
v3.13-11367-g38dbfb59d117
> cp arch/mips/configs/qi_lb60_defconfig .config
> ARCH=mips make savedefconfig
scripts/kconfig/conf --savedefconfig=defconfig Kconfig
> grep USB_ETH defconfig
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
.. but yes, as we've been saying ... if you run that through oldnoconfig
first, then save the config, you get the =y propagating.
I'd argue that the oldconfig and savedefconfig are bugs, but I'm not
motivated enough to actually try and fix them at the moment :P
Having authored my fair share of Kconfig patches, it is a strange
and wonderful world :)
>
>
> $ cp defconfig .config
> ‘defconfig’ -> ‘.config’
> $ make oldnoconfig
> scripts/kconfig/conf --olddefconfig Kconfig
> #
> # configuration written to .config
> #
> $ grep USB_ETH .config
> CONFIG_USB_ETH=y
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
>
>
>>> I believe my commit message is actually right and something went wrong
>>> in your tests.
>>
>> Heh, then we are at a stalemate. I used a stock 3.14 kernel, and my
>> results stand, and in my testing, your results with the savedefconfig
>> flow don't match.
>>
>
> Please check again, maybe you had CONFIG_USB_ETH=m in your defconfig ?
If you save it first, then yes, you do get it set to =m. It's all about
the flow.
>
>
>> Use the mips example in the changelog then .. since that one actually
>> is a consistent result.
>>
>
> Ok, I can do that.
>
>>>
>>> I understand that it may change the behaviour for some existing
>>> configurations but I believe it is the correct behaviour to actually
>>> respect what is in the kernel config provided by the user.
>>
>> On that point, I disagree. It is respecting the default values, not
>> the config provided by the user. If the user wants full control, they
>> can supply a full .config, or fragments.
>>
>
> I'm not sure I follow you. I have a defconfig with CONFIG_USB_ETH=y and
> I ended with a kernel compiled with CONFIG_USB_ETH=m. I don't think this
> is sane. It would not be necessary to provide a full kernel .config if
> the config options provided in the defconfig were respected.
See above, it varies based on the workflow, at least in my experience.
>
>
>>>
>>>> kernel_do_configure() {
>>>> # fixes extra + in /lib/modules/2.6.37+
>>>> # $ scripts/setlocalversion . => +
>>>> @@ -325,7 +327,7 @@ kernel_do_configure() {
>>>> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>>>> cp "${WORKDIR}/defconfig" "${B}/.config"
>>>> fi
>>>> - yes '' | oe_runmake oldconfig
>>>> + eval ${KERNEL_CONFIG_COMMAND}
>>>> }
>>>> --->----->--->----->--->----->--->----->
>>>>
>>>> Doing a v3 of the fallback version, with a checked commit log and
>>>> perhaps even the command flexibility would keep everyone happy and
>>>> I can add my Acked-by to that version.
>>>>
>>>
>>> BTW, I've been told by the kconfig maintainers that the preferred way of
>>> doing it would be to copy the provided defconfig to
>>> arch/${ARCH}/configs/oe_defconfig and then oe_runmake oe_defconfig. But
>>
>> linux-yocto* doesn't use defconfigs, and defconfigs can cause plenty of
>> pain, so opinions vary on this and anyone with a custom kernel recipe
>> is free to use defconfigs from within the tree, but making the generic
>> build change to that .. risks jiggling things for no obvious gain.
>>
>
> linux-yocto is not the only user of kernel.bbclass. meta-fsl-arm and
definitely not, that wasn't what I was trying to imply .. I'm looking
for flexibility precisely because there are many different users.
> meta-fs-arm-extra are using defconfigs and Otavio would prefer not
> having full configs which I understand (and isn't the name used by
> kernel.bbclass "defconfig" misleading then ?).
It's defconfig in the traditional sense, a collection of options that
are the default / baseline configuration for a board. These new fangled
savedefconfigs, olddeconfig, etc, options are all just too new :)
>
> Anyway, let me prepare a v3 and see if we all agree on that (and I
> believe we will :) ).
As do I!
Bruce
>
^ permalink raw reply [flat|nested] 20+ messages in thread