Patchwork [RFC+PATCH] mark deprecated kconfig options

login
register
about
Submitter Patrick Georgi
Date 2010-02-28 22:32:42
Message ID <4B8AEF0A.5030701@georgi-clan.de>
Download mbox | patch
Permalink /patch/996/
State Accepted
Commit r5209
Headers show

Comments

Patrick Georgi - 2010-02-28 22:32:42
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>

Patch

Index: src/Kconfig
===================================================================
--- src/Kconfig	(revision 5174)
+++ src/Kconfig	(working copy)
@@ -179,28 +179,6 @@ 
 	  This variable specifies whether a given board has a hard_reset
 	  function, no matter if it's provided by board code or chipset code.
 
-config BOARD_HAS_HARD_RESET
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a reset.c
-	  file containing a hard_reset() function.
-
-config BOARD_HAS_FADT
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a board-local
-	  FADT in fadt.c. Long-term, those should be moved to appropriate
-	  chipset components (eg. southbridge)
-
-config HAVE_BUS_CONFIG
-	bool
-	default n
-	help
-	  This variable specifies whether a given board has a get_bus_conf.c
-	  file containing bus configuration data.
-
 config HAVE_INIT_TIMER
 	bool
 	default n if UDELAY_IO
@@ -485,3 +463,5 @@ 
 config ID_SECTION_OFFSET
 	hex
 	default 0x10
+
+source src/Kconfig.deprecated_options
Index: src/Kconfig.deprecated_options
===================================================================
--- src/Kconfig.deprecated_options	(revision 0)
+++ src/Kconfig.deprecated_options	(revision 0)
@@ -0,0 +1,33 @@ 
+# Options in this file are meant to be deprecated. Avoid their use
+# if possible, and if you find the time, or touch the general area
+# for other purposes, please consider removing their uses.
+
+# It might be possible to consolidate hard_reset() to southbridges,
+# given that it (usually) uses its registers.
+# The long term goal would be to eliminate hard_reset from boards.
+config BOARD_HAS_HARD_RESET
+        bool
+        default n
+        help
+          This variable specifies whether a given board has a reset.c
+          file containing a hard_reset() function.
+
+# It might be possible to consolidate FADTs to southbridges. This would
+# improve code reuse in the tree.
+config BOARD_HAS_FADT
+        bool
+        default n
+        help
+          This variable specifies whether a given board has a board-local
+          FADT in fadt.c. Long-term, those should be moved to appropriate
+          chipset components (eg. southbridge)
+
+# There ought to be a better place to put data than code. Also, make this
+# (or a similar) framework more universally usable, so all boards benefit
+# from sharing data between the various tables.
+config HAVE_BUS_CONFIG
+        bool
+        default n
+	help
+	  This variable specifies whether a given board has a get_bus_conf.c
+	  file containing information about bus routing.