Hi,
Stefan asked me what we win if we move build behaviour from mainboard-specific Makefiles to mainboard-specific Kconfig files (eg. BOARD_HAS_FADT).
I introduced these flags so I can rework the build system without too much risk of breaking boards at runtime. Several of the per-mainboard things can probably be moved to the southbridge code (see patch), but that would require functional testing. For moving build rules around, a build test is usually good enough.
A config flag is also less flexible, and all the "complicated" logic is at a single place now (src/arch/i386/Makefile.inc mostly), instead of replicated several times at various boards.
It's harder for such a flag to hide, or for developers to modify it in a way that leads to a multitude of similar-but-not-quite variants of the associated feature.
To make it even more obvious which features should change (and how), I propose to add a new Kconfig file, included by the main src/Kconfig, at src/Kconfig.deprecated_options.
The new Kconfig file will host the options that might go away once certain parts of the tree are refactored, and as such acts as an up-to-date TODO list of such things. As an example, I moved the options I recently created there, with documentation on what they do (help text) and how they could be eliminated (as comments).
Once an option falls out of use, because all its users are refactored appropriately, it can be dropped there, and no todo list will be forgotten in the process. If it can be shown that deprecation candidates really need to exist, they can be moved to some permanent location.
The list of options in the patch is not exhaustive - I'm quite sure that there are more of these that really belong into this list, but I wanted to pick a relatively safe set, so we can discuss the merit of the approach, instead of the actual selection of options to deprecate.
Patch is Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de