On Thu, 18 Sep 2014, Paul Bolle wrote: > 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"). ah, cool ... i was just using random examples from linus' tree. used to be, the tree was *full* of this sort of thing, now there's way less of it. progress, baby. > > 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. i'm pretty sure i had this conversation once upon a time, possibly on LKML, and the pretty firm consensus is that "CONFIG_" should be reserved for Kconfig variables, but i don't have a link to it. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
