Hi Tom, On Fri, Jun 5, 2015 at 11:25 AM, Tom Rini <tr...@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.hershber...@gmail.com>: >> > Hi Masahiro-san, >> > >> > On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada >> > <yamada.masah...@socionext.com> wrote: >> >> 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. >> > >> > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
