From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Thu, 04 Jun 2015 12:18:39 +0200 Subject: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default In-Reply-To: References: <1433355136-13627-1-git-send-email-hdegoede@redhat.com> <20150603221210.GV1728@bill-the-cat> <20150603222658.GW1728@bill-the-cat> Message-ID: <557025FF.9050600@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 04-06-15 00:55, Joe Hershberger wrote: > On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini 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 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 >>>>> Reported-by: Maxin B. John >>>>> Signed-off-by: Hans de Goede >>>> >>>> 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! >>> >>> 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. Well taking CMD_NET as example, most boards may not have (wired) ethernet but they often to have USB and u-boot supports several popular USB <-> ethernet adapters... TBH given modern system memory sizes I think it makes sense for a lot of stuff to just default to y, and then one really space / mem constrained systems they can be disabled via a select from the ARCH setting. > 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. > > 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? Regards, Hans