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