Hi.
2015-06-04 7:55 GMT+09:00 Joe Hershberger <joe.hershber...@gmail.com>: > On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini <tr...@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 <tr...@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.j...@enea.com> >>> >> Reported-by: Maxin B. John <maxin.j...@enea.com> >>> >> Signed-off-by: Hans de Goede <hdego...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
