if anyone wants to play with my kernel cleanup scripts ...

[pebolle@tiscali.nl (Paul Bolle)]

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