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

[Masahiro Yamada]

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.



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

Network functions are often useful during development and debugging,
but might not for mass-production, for example.


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



-- 
Best Regards
Masahiro Yamada