Hi Wolfgang,
On Wed, 19 Mar 2014 10:56:46 +0100
Wolfgang Denk <w...@denx.de> wrote:
> Dear Masahiro,
>
> In message <20140319135026.7a64.aa925...@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 <twar...@nvidia.com>:Stephen
> > > >>> Warren <swar...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
