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

>