All of lore.kernel.org
 help / color / mirror / Atom feed
From: rpjday@crashcourse.ca (Robert P. J. Day)
To: kernelnewbies@lists.kernelnewbies.org
Subject: if anyone wants to play with my kernel cleanup scripts ...
Date: Thu, 18 Sep 2014 06:57:27 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1409180649010.25541@localhost> (raw)


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

             reply	other threads:[~2014-09-18 10:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 10:57 Robert P. J. Day [this message]
2014-09-18 11:13 ` if anyone wants to play with my kernel cleanup scripts Paul Bolle
2014-09-18 11:57   ` Robert P. J. Day
2014-09-18 12:13     ` Paul Bolle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.11.1409180649010.25541@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.