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

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

[Robert P. J. Day]

... 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 */
>>>>> 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

  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.

  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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

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

[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

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

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

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

[Paul Bolle]

On Thu, 2014-09-18 at 07:57 -0400, Robert P. J. Day wrote:
> On Thu, 18 Sep 2014, Paul Bolle wrote:
> > 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.

That "pretty firm consensus" makes sense to me. But please post that
link, in this thread, if you ever stumble on it.

(Side note: I do think the CONFIG_ prefix is too generic.

And I think it would have been easier if the Kconfig symbols themselves
would have kept that prefix. They used to have it in 2.4 and earlier, I
seem to remember. I don't know why that was changed.

But there's little we can do about these two things now , anyhow.)


Paul Bolle