On Thu, 2014-09-18 at 06:57 -0400, Robert P. J. Day wrote:
... i've been tidying them up a bit and rerunning them to get up-to-date output as examples:
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
and as i know greg kh follows this list, i thought the following output from running the "badref" script on drivers/staging was interesting (it's reproduced on the wiki page as sample output):
B4860G100 drivers/staging/gs_fpgaboot/io.c:34:#ifdef CONFIG_B4860G100 drivers/staging/gs_fpgaboot/io.c:36:#endif /* CONFIG_B4860G100 */ drivers/staging/gs_fpgaboot/io.c:95:#ifdef CONFIG_B4860G100 drivers/staging/gs_fpgaboot/io.c:300:#endif /* CONFIG_B4860G100 */
See linux-next commit 06a3fab941da ("staging: gs_fpgaboot: remove checks for CONFIG_B4860G100").
FORCE_HARD_FLOAT drivers/staging/rtl8192u/r8192U_core.c:27:#ifndef CONFIG_FORCE_HARD_FLOAT MACH_EMGR drivers/staging/emxx_udc/emxx_udc.h:440:#ifdef CONFIG_MACH_EMGR
See linux-next commit 5e5d7443646d ("staging: emxx_udc: remove check for CONFIG_MACH_EMGR").
what the above purportedly shows is that, under the entire drivers/staging directory, there are three examples of CONFIG_* variables that are referenced in some way in a source or header file that are not defined in any Kconfig file in the entire source tree.
it's up to the authors to fix that any way they want, but the second example ("CONFIG_FORCE_HARD_FLOAT") deserves more explanation. here's the result of a tree-wide grep:
$ grep -r FORCE_HARD_FLOAT * drivers/staging/rtl8192u/Makefile:ccflags-y += -DCONFIG_FORCE_HARD_FLOAT=y drivers/staging/rtl8192u/r8192U_core.c:#ifndef CONFIG_FORCE_HARD_FLOAT $
so while that variable is not defined in a Kconfig file, it *is* actually defined as a flag in the associated Makefile, which is a *no-no* -- the very established tradition is that the variable prefix "CONFIG_" is reserved for Kconfig variables *only*. if that variable *used* to be set in a Kconfig file, but was subsequently moved to a Makefile, tradition suggests the "CONFIG_" prefix should have been dropped.
I tend to agree. There are two dozen hits for this: $ git grep -e -DCONFIG_ next-20140918 | wc -l 24 In total there are only a handful of Kconfig like macros defined like this. Some of them might be hard to change now. I've never tried. See also things like: #define CONFIG_FOO and: enum foo { CONFIG_FOO = 1, }; I try to holler when a new one of these enters linux-next. Very few people seems to share this pet peeve.
anyway, you find all sorts of interesting things scanning the kernel tree. feel free to play and suggest fixes to those scripts -- i'm sure they have bugs in them.
Paul Bolle