[PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

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

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 61a6d102d7a8..644d7937923d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -313,7 +313,7 @@ kernel_do_configure() {
 	if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
 		cp "${WORKDIR}/defconfig" "${B}/.config"
 	fi
-	yes '' | oe_runmake oldconfig
+	oe_runmake oldnoconfig
 }
 
 do_savedefconfig() {
-- 
1.8.3.2

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Tue, Jan 07, 2014 at 03:18:37PM +0100, 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.

Looks good, I have few kernel recipes where I had to fixup resulting
.config after "make savedefconfig", "yes '' | make oldconfig" combo
exactly because of some =y changing to -m.

1) Do you know since when oldnoconfig is supported?

IIRC oldest kernel I've in BSPs is 2.6.24. 

2) Could you send similar patch for
meta-openembedded/meta-oe/recipes-kernel/linux/linux.inc
?

>  $ 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
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  meta/classes/kernel.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 61a6d102d7a8..644d7937923d 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -313,7 +313,7 @@ kernel_do_configure() {
>  	if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>  		cp "${WORKDIR}/defconfig" "${B}/.config"
>  	fi
> -	yes '' | oe_runmake oldconfig
> +	oe_runmake oldnoconfig
>  }
>  
>  do_savedefconfig() {
> -- 
> 1.8.3.2
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

On 07/01/2014 15:35, Martin Jansa wrote:
> On Tue, Jan 07, 2014 at 03:18:37PM +0100, 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.
> 
> Looks good, I have few kernel recipes where I had to fixup resulting
> .config after "make savedefconfig", "yes '' | make oldconfig" combo
> exactly because of some =y changing to -m.
> 
> 1) Do you know since when oldnoconfig is supported?
> 
> IIRC oldest kernel I've in BSPs is 2.6.24. 

oldnoconfig seems to be present since 2.6.36. olddefconfig is an alias
that appeared with fb16d8912db5268f29706010ecafff74b971c58d which is
present since v3.7.

Then hat about using:

oe_runmake oldnoconfig || yes '' | oe_runmake oldconfig

> 
> 2) Could you send similar patch for
> meta-openembedded/meta-oe/recipes-kernel/linux/linux.inc
> ?
> 

Sure, will do once we agreed on this patch



-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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 ?

.. 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.

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.

Bruce

>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>   meta/classes/kernel.bbclass | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 61a6d102d7a8..644d7937923d 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -313,7 +313,7 @@ kernel_do_configure() {
>   	if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>   		cp "${WORKDIR}/defconfig" "${B}/.config"
>   	fi
> -	yes '' | oe_runmake oldconfig
> +	oe_runmake oldnoconfig
>   }
>
>   do_savedefconfig() {
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On Tue, Jan 07, 2014 at 04:20:37PM +0100, Alexandre Belloni wrote:
> On 07/01/2014 15:35, Martin Jansa wrote:
> > On Tue, Jan 07, 2014 at 03:18:37PM +0100, 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.
> > 
> > Looks good, I have few kernel recipes where I had to fixup resulting
> > .config after "make savedefconfig", "yes '' | make oldconfig" combo
> > exactly because of some =y changing to -m.
> > 
> > 1) Do you know since when oldnoconfig is supported?
> > 
> > IIRC oldest kernel I've in BSPs is 2.6.24. 
> 
> oldnoconfig seems to be present since 2.6.36. olddefconfig is an alias
> that appeared with fb16d8912db5268f29706010ecafff74b971c58d which is
> present since v3.7.
> 
> Then hat about using:
> 
> oe_runmake oldnoconfig || yes '' | oe_runmake oldconfig

Looks safer (assuming that oldnoconfig will return error only in cases
where oldnoconfig target doesn't exist in Makefile, otherwise fall-back
to yes '' could be a bit confusing).

In worst case you can add KERNEL_VERSION check or show bb.warn when
oldnoconfig isn't supported.

> > 2) Could you send similar patch for
> > meta-openembedded/meta-oe/recipes-kernel/linux/linux.inc
> > ?
> > 
> 
> Sure, will do once we agreed on this patch

Thanks

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Hart, Darren]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

On Tue, 2014-01-07 at 16:54 +0100, Martin Jansa wrote:
> On Tue, Jan 07, 2014 at 04:20:37PM +0100, Alexandre Belloni wrote:
> > On 07/01/2014 15:35, Martin Jansa wrote:
> > > On Tue, Jan 07, 2014 at 03:18:37PM +0100, 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.
> > > 
> > > Looks good, I have few kernel recipes where I had to fixup resulting
> > > .config after "make savedefconfig", "yes '' | make oldconfig" combo
> > > exactly because of some =y changing to -m.
> > > 
> > > 1) Do you know since when oldnoconfig is supported?
> > > 
> > > IIRC oldest kernel I've in BSPs is 2.6.24. 
> > 
> > oldnoconfig seems to be present since 2.6.36. olddefconfig is an alias
> > that appeared with fb16d8912db5268f29706010ecafff74b971c58d which is
> > present since v3.7.
> > 
> > Then hat about using:
> > 
> > oe_runmake oldnoconfig || yes '' | oe_runmake oldconfig
> 
> Looks safer (assuming that oldnoconfig will return error only in cases
> where oldnoconfig target doesn't exist in Makefile, otherwise fall-back
> to yes '' could be a bit confusing).
> 
> In worst case you can add KERNEL_VERSION check or show bb.warn when
> oldnoconfig isn't supported.

Please check for the functionality, not KERNEL_VERSION. The
KERNEL_VERSION doesn't allow for backports and such which might add this
ability. Grep the Makefile for the target, for example, if the above OR
statement isn't adequate.

As Bruce stated, it seems that the fix would be to use the updated
Kconfig, not default to setting things to NO. The problem with that
approach is it doesn't accept defaults for non-specified options (which
when updating kernel versions, is often the preferred approach).


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

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.

As shown in my commit log, using yes '' | make oldconfig is still
getting it wrong.

> .. 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 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.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

On 07/01/2014 19:11, Hart, Darren wrote:
> 
> Please check for the functionality, not KERNEL_VERSION. The
> KERNEL_VERSION doesn't allow for backports and such which might add this
> ability. Grep the Makefile for the target, for example, if the above OR
> statement isn't adequate.
> 

I guess the OR is perfectly fine then. For whatever reason make
oldnoconfig fails, we'll fall back to the old behavior.

> As Bruce stated, it seems that the fix would be to use the updated
> Kconfig, not default to setting things to NO. The problem with that
> approach is it doesn't accept defaults for non-specified options (which
> when updating kernel versions, is often the preferred approach).
> 

I think you got it wrong:
 - I am already using an updated kconfig (I even backported it on the
older kernel version)
 - make oldnoconfig is NOT setting things to NO but to the default value
of the unspecified options (exactly what we need). The choice of the
name was not wise and It has been renamed olddefconfig since 3.7


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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.
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

On 07/01/2014 21:39, Bruce Ashfield wrote:

>>
>> 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.
> 

Hum, I'm not sure I follow you. oldnoconfig and olddefconfig are exactly
the same. oldnoconfig has been renamed olddefconfig in 3.7 and
oldnoconfig is an alias to olddefconfig since then. I'm using
oldnoconfig only to be able to use that on a wider range of kernel versions.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

On 14-01-07 03:52 PM, Alexandre Belloni wrote:
> On 07/01/2014 21:39, Bruce Ashfield wrote:
>
>>>
>>> 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.
>>
>
> Hum, I'm not sure I follow you. oldnoconfig and olddefconfig are exactly
> the same. oldnoconfig has been renamed olddefconfig in 3.7 and
> oldnoconfig is an alias to olddefconfig since then. I'm using
> oldnoconfig only to be able to use that on a wider range of kernel versions.

I need to go run some of my own tests (and poke that the code). I'm
running out of time for the day, so need to have a closer look when
things slow down.

I'm not so much concerned about the differences between:

   defconfig -> savedefconfig -> config

and

   defconfig -> new kernel (oldconfig) -> config

vs

   defconfig -> new kernel (olddefconfig) -> config

i.e. What do the new config options offered by the new kernel
generate in the final .config between the two techniques.

Personally, I think the make target that is run should be configurable
via a variable (yes, I know we all hate new variables), but getting
this right for everyone is hard, and also not forcing everyone to write
their own kernel_do_configure() if they don't like this behaviour.

Bruce

>
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Hart, Darren]

On Tue, 2014-01-07 at 21:32 +0100, Alexandre Belloni wrote:
> On 07/01/2014 19:11, Hart, Darren wrote:
> > 
> > Please check for the functionality, not KERNEL_VERSION. The
> > KERNEL_VERSION doesn't allow for backports and such which might add this
> > ability. Grep the Makefile for the target, for example, if the above OR
> > statement isn't adequate.
> > 
> 
> I guess the OR is perfectly fine then. For whatever reason make
> oldnoconfig fails, we'll fall back to the old behavior.
> 
> > As Bruce stated, it seems that the fix would be to use the updated
> > Kconfig, not default to setting things to NO. The problem with that
> > approach is it doesn't accept defaults for non-specified options (which
> > when updating kernel versions, is often the preferred approach).
> > 
> 
> I think you got it wrong:
>  - I am already using an updated kconfig (I even backported it on the
> older kernel version)
>  - make oldnoconfig is NOT setting things to NO but to the default value
> of the unspecified options (exactly what we need). The choice of the
> name was not wise and It has been renamed olddefconfig since 3.7
> 
> 

I see - you're right, I had misunderstood.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

Hi Bruce,

Any news on that ?

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.
> >
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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.
>>>
>>
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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.
>>>
>>
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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.
>>>
>>
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

[-- 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 --]

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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.
>
>

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Alexandre Belloni]

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

Re: [PATCH] kernel: use oldnoconfig instead of yes '' | make oldconfig

[Bruce Ashfield]

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

>