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

[rpjday@crashcourse.ca (Robert P. J. Day)]

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
========================================================================