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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
