[U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default

[Joe Hershberger]

Hi Masahiro-san,

On Thu, Jun 4, 2015 at 11:02 PM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> Hi Joe,
>
>
> 2015-06-05 2:54 GMT+09:00 Joe Hershberger <joe.hershberger at gmail.com>:
>> Hi Masahiro-san,
>>
>> On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada
>> <yamada.masahiro at socionext.com> wrote:
>>> Hi.
>>>
>>>
>>> 2015-06-04 7:55 GMT+09:00 Joe Hershberger <joe.hershberger at gmail.com>:
>>>> On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini <trini at konsulko.com> wrote:
>>>>> On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote:
>>>>>> Hi Tom,
>>>>>>
>>>>>> On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini <trini at konsulko.com> wrote:
>>>>>> > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote:
>>>>>> >
>>>>>> >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then
>>>>>> >> needing to have this in every sunxi defconfig file.
>>>>>> >>
>>>>>> >> This also fixes the Merrii_A80_Optimus defconfig no longer building.
>>>>>> >>
>>>>>> >> Cc: Maxin B. John <maxin.john at enea.com>
>>>>>> >> Reported-by: Maxin B. John <maxin.john at enea.com>
>>>>>> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>>>> >
>>>>>> > Joe? Masahiro?  It feels like something has gone wrong with the
>>>>>> > conversion here.  Or do people need to get used to the defconfig files
>>>>>> > being a non-trivial size?  Or do we need some more default y if ...
>>>>>> > lines around things?  Or a few of the above?  Thanks!
>>>
>>>
>>> I think too much (ab)use of "default y if ..." in board Kconfigs is wrong.
>>
>> I completely agree. I'd like to see them all go away, but maybe that's
>> just me. Doing this even causes the help for the option to incorrectly
>> indicate where that token is defined - it indicates the first default
>> setting inside some arch that's not even yours and not the real
>> definition location.
>
> Joe, you are not alone.
>
> I see another problem for adding default entries to board Kconfigs.
>
> If you see commit ece26f623c93afe95821f89d4dd53ae8f3cfa1b6,
> you will notice CONFIG_NET=y and CONFIG_NET_RANDOM_ETHADDR=y
> were added to separate places in defconfig files.
> (Please note the defconfigs were sorted by savedefconfig.)
>
> They should have been lined up together because their real definitions
> are placed in net/Kconfig.
>
> At the point when I posted the patch, board/sunxi/Kconfig had the
> default setting:
>
> config NET
>         default y
>
> so savedefconfig put CONFIG_NET=y much earlier than it should be.
>
>
> Periodical attempt for cleaning defconfigs by savedefconfig comes to nothing
> because the order changes every single time someone adds a default
> entry into his board Kconfig.

I had not noticed that, but it's an even more compelling reason to
simply disallow it entirely.

>>>>>> It seems we should select good defaults. Maybe we should try to agree
>>>>>> which way we should err. Make u-boot bigger by default, and boards
>>>>>> that are limited can disable features? Or should we enable commands on
>>>>>> boards that "need" a feature and keep u-boot slim by default?
>>>>>>
>>>>>> I don't like the half measure of defining a different default for one
>>>>>> platform than another unless it is actually something inherent in the
>>>>>> platform, and in that case it should be enabled by a "selects" under
>>>>>> the platform Kconfig.
>>>>>>
>>>>>> I agree we want to have smaller defconfigs rather than bigger, but
>>>>>> there are lots of features and many boards will not agree, so the
>>>>>> defconfigs of many boards will have to contain something.
>>>>>
>>>>> The first thing that pops to mind is that if it used to be in
>>>>> config_cmd_default.h it should be on by default and disabled when needed
>>>>> (and this means we can be smart about CMD_FLASH / CMD_IMLS).  Otherwise
>>>>> we need to think hard on if something new should be on by default or
>>>>> not.
>>>>
>>>> I have the gut feeling that things that depend on hardware existing
>>>> (such as CMD_NET) should not be default.  However, I guess if it's
>>>> totally ubiquitous (such as CMD_MEMORY - though it's already in
>>>> config_cmd_default.h) then it should be default just to shrink the
>>>> defconfigs.
>>>
>>>
>>> Even if your board has a network device,
>>> you may not want to enable it by default in some cases.
>>
>> This is the reason for not making it a platform "selects X_FEATURE",
>> but defaults are just that.
>>
>>> Network functions are often useful during development and debugging,
>>> but might not for mass-production, for example.
>>
>> Do you think many (or any) boards are mass-produced based on the
>> main-line defconfigs?
>
> No, I think they are mostly for development boards.
>
> Anyway, U-boot without network makes sense.

For sure!

>>>> Ian, you indicated that you thought CMD_NET should be a default since
>>>> it is usually wanted. It seems that is generally the case. It looks
>>>> like 94% of boards enable CMD_NET, which makes it pretty much
>>>> ubiquitous.
>>>>
>>>> Perhaps that should be the metric for deciding (probably with
>>>> flexibility for making an argument to the contrary)... if more that
>>>> 80% (good enough water-mark?) of the boards enable a feature, then it
>>>> should be the default?  50% would optimize for overall defconfig
>>>> size... maybe that's better?
>>>
>>> The "Ubiquitous" thing is one criteria, but I prefer the best judge
>>> for each CONFIG.
>>
>> It would help to have an idea of the criteria you would use to judge
>> it. What do you do you consider important criteria?
>
> I cannot describe it well, but I guess a kind of common sense.
>
>
>>> I think the default value should be well-reviewed, because once we
>>> decide the default y (or n)
>>> it is hard to invert it later.
>>
>> It is actually easy now with my new patch to moveconfig:
>> https://patchwork.ozlabs.org/patch/478053/
>
>
> It is true that in-tree boards are correctly converted,
> but boards that are going be merged in near future might
> have opposite configs of authors' intention.

That is true, and we will all have to be careful. Hopefully
maintainers pulling in new boards can watch for this. Maybe we should
start a Wiki page that lists the configs that we change the default on
and the date that it hit mainline so that board contributors and
maintainers have a place to look to check their defconfig.

Cheers,
-Joe