[U-Boot-Users] [PATCH] lkc support for U-Boot

[Holger Schurig]

> Why are all these things named ARCH_*?

They don't have to.

But in the Linux kernel they are all called CONFIG_ARCH_<boardname>. At least 
in the ARM tree, the one I'm familiar with:

#
# System Type
#
# CONFIG_ARCH_ANAKIN is not set
# CONFIG_ARCH_ARCA5K is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
CONFIG_ARCH_PXA=y
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_CAMELOT is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_MX1ADS is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_RISCSTATION is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_SHARK is not set

> > So it is absolutely no problem to have in
> > u-boot/boards/<someboard>/config.in an entry like
>
> But that means that the configuration for one  board  is  distributed
> over  3 (or more?) config.in files. It has certain advantages to have
> it concentrated in one place...

The actual configuration is in the .config file --- and can be in the 
per-board directory as a def-config.

But what is configurable (the meta-configuration) info is distributed. 
Ideally, in each directory where some *.C or *.H files implement features the 
corresponding config.in file contains the meta-information of what the 
feature does, how it is named, how it relates to other config infos.


> I disagree. It is much more complicated to find  all  config  options
> relevant  to  once  specific  system,  and  requires  a  much  better
> understanding  of  the  config  mechanism  to   add   a   new   board
> configuration - correctly, that is.

Now. The one that is responsible for a board, e.g. the maintainer of the PP405 
board, once uses the menuconfig to set up all the options for this board. 
Then he does a simple "cp .config board/pp405/def-config" and ask you to 
check in this file.

If this board specifies a new command (e.g. CONFIG_PP405_TOGGLE_LED) then the 
code for this command is in boards/pp405/cmd_toggle.c. And the sheer 
existence of this new feature is also in boards/pp405/config.in. So the 
things are near to each other.

If you, on the other side, make a new general command that is not hardware 
related, then you add common/cmd_tetris.c, include/cmd_tetris.h, and in 
common/config.in you add the command definition:

define CMD_TETRIS
  bool "tetris: ever played tetris over a serial line?"
  default "n"

If now our PP405 guy dows a checkout and

  cp boards/pp405/def-config .config
  make oldconfig

then he still has not the new command selected. But it would appear on his 
make menuconfig/make xconfig screen to be selectable, clearly marked as 
"tetris: ever played tetris over a serial line? (NEW)". He can then create a 
new def-config if he wants to have this command on his platform. Or keep it 
as is.

If you now do this using the current approach, then a maintainer for a board 
would have to check from time to time the include/cmd_confdefs.h for new 
things on the radar and would 

In this case, the new command (cmd_tetris.c) and the definition of it's 
existence etc is in the same directory. For me this sounds easy to maintain.

Greetings, Holger

-- 
MN-Logistik GmbH         http://www.mn-logistik.de
Holger Schurig
Dieselstr. 18
61191 Rosbach v.d.Höhe
Tel: 06003/9141-0        Fax: 06003/9141-49