In message 200211071011.59506.h.schurig@mn-logistik.de you wrote:
Why are all these things named ARCH_*?
They don't have to.
Then we should not do that.
But in the Linux kernel they are all called CONFIG_ARCH_<boardname>. At least in the ARM tree, the one I'm familiar with:
Yes, I know, and never understood. Actually I consider this a bug; for example, we support both the SMDK2400 and TRAB boards, which use the same architecture and the same CPU (Samsunf s3c2400). 95% of the code that needs to be #ifdef'ed is CPU dependend, so I think we should have a CONFIG_ARCH_S3C2400 plus either a CONFIG_SMDK2400 or CONFIG_TRAB (or maybe that should be CONFIG_BOARD_SMDK2400) etc.
# # 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
...
I know. This design is broken.
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.
Understood. Well, I have to admit that I will have to get used to this idea.
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
Most boards use either a carefully selcted combinations of wanted options, or a selection of excluded options, so this happens automagically.
Best regards,
Wolfgang Denk