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

[Wolfgang Denk]

Dear Masahiro,

In message <20140319135026.7A64.AA925319 at 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 at nvidia.com>:Stephen Warren <swarren at 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.

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.

> There is  a plan to move user-editable macros to Kconfig.
> For example,  CONFIG_BAUDRATE.

Yes, this is a good example for a setting where the user might want
to adjust a setting, and where it is harmless to do so.

> Or someone might to disable CONFIG_CMD_*  to reduce
> the binary size.

Agreed, too - a user may want to enable (or disable) a specific set of
commands in his configuration - but this is already one of the more
complicated cases, as there will be a ton of dependencies you will
have to include.

On the other hand, a user should probably not be able to change the
maintainer name, and similar so for a large number of other values.
Following the originally intended logic of the naming scheme, only the
CONFIG_ variables should show up here, where CONFIG_SYS_ variables
should be not changable like this - or at least require some specific
"expert menu" mode.

> We definitely need "defconfig".

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.


> 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).


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone can count the seeds in an apple.
No one can count the apples in a seed.