[U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards

[Masahiro Yamada <yamada.m@jp.panasonic.com>]

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