Hi Wolfgang,
On Wed, 19 Mar 2014 10:56:46 +0100 Wolfgang Denk wd@denx.de wrote:
Dear Masahiro,
In message 20140319135026.7A64.AA925319@jp.panasonic.com you wrote:
+++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU="armv7" +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC="tegra30" +CONFIG_SYS_BOARD="beaver" +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR="nvidia" +CONFIG_SYS_CONFIG_NAME="beaver" +CONFIG_BOARD_MAINTAINER="Tom Warren twarren@nvidia.com:Stephen Warren swarren@nvidia.com"
This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing.
In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a.
I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work.
Right. None of settings in Kconfig in this series is not user-editable. "make randconfig" or "make allyesconfig" will not work at all.
I'm not sure if I understand your double negation here correctly. Avoiding the double negation, you state that ALL values in this defconfig are user-editable.
Oops, sorry. What I wanted to say is: None of settings in Kconfig in this series is user-editable.
I fully agree with Stephen that this should not be the case.
I'm afraid we are approaching one of the areas where we run into problems if we try to reuse Kconfig as done in Linux, without changes.
As Stephen already explained, we have the situation that there are certain settings that are not actually supported to be user-editable.
If "prompt" is not specified, the entry will not appear on "make config", "make menuconfig", etc.
Linux Kernel does this for user-uneditable CONFIG.
The following is a snippet from arch/arm/Kconfig of Linux Kernel.
<<<<<<<<<<<<< config STACKTRACE_SUPPORT bool default y
config HAVE_LATENCYTOP_SUPPORT bool depends on !SMP default y
config LOCKDEP_SUPPORT bool default y
config TRACE_IRQFLAGS_SUPPORT bool default y
config RWSEM_GENERIC_SPINLOCK bool default y
>>>>>>>
Above are forced to the default value. We should do this in U-Boot too.
This is OK - the question is, what should it contain. In my opinion, we should fiond here the user changable settings (i. e. CONFIG_ stuff), but not the "unchangable" things (like CONFIG_SYS_).
Yes, I am aware that there is a lot of incorrectly chosen names, i. e. cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this adds to the complexity of converting to Kconfig.
For example, CONFIG_SYS_PROMPT.
I believe the right way to reuse the Linux's Kconfig with minimum modification.
Whithout modification, we will probably have to restrict ourself to the really simple, user-configurable options - i. e. the CONFIG_ set of options (and even then we will either have to make a number of exceptions, and/or rename a number of such names, and/or provide in some cases quite complex dependencies).
This is the outcome we have developed. What we should do it to fix them correctly, not to change Kconfig concept.
Best Regards Masahiro Yamada