[PATCH][RFC] Add a script to locate "dead" CONFIG variables.

[Robert P. J. Day]

Add a script that scans any part of the source tree for references to
CONFIG_-prefixed variables that aren't defined in any Kconfig file.

Signed-off-by: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx>

---

  might as well just toss this into the tree.

diff --git a/scripts/find_dead_configs.sh b/scripts/find_dead_configs.sh
new file mode 100755
index 0000000..df68773
--- /dev/null
+++ b/scripts/find_dead_configs.sh
@@ -0,0 +1,90 @@
+#!/bin/sh
+#
+#  find_dead_configs.sh
+#
+#  This script scans either all or any selected subdirectory of
+# the kernel source tree and identifies "dead" CONFIG variables;
+# that is, preprocessor tests in any source or header file which
+# test a symbol with a name like "CONFIG_FUBAR" for which there
+# is no associated "config FUBAR" entry in any Kconfig* file
+# anywhere in the entire tree.
+#
+#  This script should always be run from the top-level directory
+# of the tree.  Some sample invocations:
+#
+#    $ .../find_dead_configs.sh fs/
+#    $ .../find_dead_configs.sh sound/
+#    $ .../find_dead_configs.sh drivers/net/
+#    $ .../find_dead_configs.sh		[default of entire tree]
+#
+#  Here's a sample run at the moment:
+#
+#    $ find_dead_configs.sh kernel
+#    ========== PROVE_SPIN_LOCKING ==========
+#    kernel/spinlock.c:308:#ifdef CONFIG_PROVE_SPIN_LOCKING
+#
+#  So kernel/spinlock.c is testing a macro that clearly is not
+# defined in any Kconfig file anywhere in the tree.
+#
+#  NOTES:
+#
+#   1)	Even if you choose to check only a subdirectory, the script
+#	will still look for the corresponding Kconfig entry everywhere
+#	in the tree, just to be thorough.
+#
+#   2)	For each symbol like "FUBAR" identified as being potentially
+#	"dead", the script will grep the entire tree for that string,
+#	just to display anything that might possibly be related.
+#	This sometimes makes typoes immediately obvious.
+#
+#   3)	Sadly, at the moment, this script does generate numerous
+#	false positives as an annoying number of developers have a
+#	bad habit of creating local macro names with a prefix of
+#	"CONFIG_".  Bad developer.  No biscuit.
+#
+#	In any event, it's your job to examine the output manually
+#	afterwards to see if there's anything of interest.
+
+DIR=${1-*}
+
+#
+#  From the selected source and header files, extract all of the
+# "CONFIG_" macro names, strip their leading "CONFIG_" and possible
+# trailing "_MODULE" strings, then uniquely sort what's left to get
+# the macro "names" we're going to sanity check.
+#
+#  As an example, if a source file contains a preprocessor test for
+# the macro CONFIG_FUBAR, the string "FUBAR" will be added to the
+# CVARS list of names to test.
+#
+
+CVARS=$(find ${DIR} -name "*.[ch]" |    \
+        xargs ifnames |                 \
+        grep "^CONFIG_" |               \
+        cut -d' ' -f1 |                 \
+        sed "s/^CONFIG_//" |            \
+        sed "s/_MODULE$//" |            \
+        sort -u)
+
+# echo "${CVARS}"
+
+#
+#  Create a list of *all* Kconfig files throughout the entire
+# tree.
+#
+
+kcfiles=$(find . -name "Kconfig*")
+
+#
+#  For every CONFIG variable that appears to be dead, scan the
+# entire tree for that string.  You just never know what might
+# turn up.
+
+for cv in ${CVARS} ; do
+        grep -wq ${cv} ${kcfiles} || {
+                echo "========== ${cv} =========="
+                grep -rwn "CONFIG_${cv}" ${DIR}
+                grep -rwn "CONFIG_${cv}_MODULE" ${DIR}
+                grep -rwn "${cv}" *
+        }
+done
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/