From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 23 Apr 2014 10:08:49 -0600 Subject: [U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support In-Reply-To: <20140423210335.18EE.AA925319@jp.panasonic.com> References: <1398159826-29398-2-git-send-email-yamada.m@jp.panasonic.com> <20140422121345.04ABA3801AC@gemini.denx.de> <20140423210335.18EE.AA925319@jp.panasonic.com> Message-ID: <5357E591.1060906@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/23/2014 06:03 AM, Masahiro Yamada wrote: > On Tue, 22 Apr 2014 14:13:44 +0200 > Wolfgang Denk wrote: >> In message <1398159826-29398-2-git-send-email-yamada.m@jp.panasonic.com> you wrote: >>> CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment >>> variables, "arch", "cpu", "board", etc. depending on >>> CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively. >>> >>> We are discussing the introduction of Kconfig. >>> In our discussion, we found boolean CONFIG macros are more useful >>> in Kconfig context. >>> >>> That is, >>> >>> CONFIG_ARM=y >>> CONFIG_CPU_ARMv7=y >>> CONFIG_BOARD_HARMONY=y >>> CONFIG_VENDOR_NVIDIA=y >>> >>> rather than >>> >>> CONFIG_SYS_ARCH="arm" >>> CONFIG_SYS_CPU="armv7" >>> CONFIG_SYS_BOARD="harmony" >>> CONFIG_SYS_VENDOR="nvidia" >> >> I understand your intention - but does this not mean that we lose all >> flexibility in assigning board and vendor names? So far, we allow any >> kind of names, lowercase and uppercase and mixed. Will we not lose >> this capability? Also, we have '-' characters in a number of board >> names - would this not also cause trouble? >> >> Finally, I don't see what your replacement code would be to create the >> set of environment settigns - and I think these are needed, as some >> user defined scripts are processing these? > > The user who needs such environment setting can > add them by using CONFIG_EXTRA_ENV_SETTINGS. > > For example, > > #define CONFIG_EXTRA_ENV_SETTINGS \ > "arch=arm\0" \ > "cpu=armv7\0" \ > "soc=tegra20\0" > > I am not sure this is acceptable. Right now, we get the values set up automatically for free. It seems like a regression to force the board maintainer to set these all up manually instead. Kconfig supports string variables. The Linux kernel stores the ARM debug_ll include filename in one for example. Perhaps using that technique would resolve the issue.