[U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default
Joe Hershberger
joe.hershberger at gmail.com
Wed Jun 10 16:09:14 CEST 2015
Hi Tom,
On Fri, Jun 5, 2015 at 11:25 AM, Tom Rini <trini at konsulko.com> wrote:
> On Fri, Jun 05, 2015 at 01:02:16PM +0900, Masahiro Yamada 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 hope that we can largely move away from "default y if ..." in the long
> term but still have "default y" (because it can be set to off).
>
>> 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 think what we're seeing here is the conflicts between "we do not want
> to enable many things by default", "we do not want to suddenly break
> users" and "we do not want super huge defconfigs".
This reordering issue makes it much worse of a problem. I think we
should simply disallow it completely. I can make a patch that removes
all of them and updates their defconfigs to include the configs.
>> >>>>> 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.
>>
>>
>> >>> 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 I agree as well. But I would say (and I'm looking at a
> no-network board right now) that CMD_NET and everything else that was/is
> in config_cmd_default.h should start out as "default y" and let the
> boards that don't need it, disable it.
>
> I also really want to avoid board/.../Kconfig from touching generic
> options like this which they will want to do to avoid breaking users.
Sounds like at least the 3 of us are in agreement...
-Joe
More information about the U-Boot
mailing list