Stefan asked me what we win if we move build behaviour from
mainboard-specific Makefiles to mainboard-specific Kconfig files (eg.
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
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
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.
Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
Show replies by date