processing the unused and "badref" CONFIG variables

[Robert P. J. Day]

  just to prod people into maybe perusing the output here:

http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables

even if *most* of those definitions of unused CONFIG variables don't
do any harm, as i mentioned, sometimes that output clearly identifies
typoes that should be fixed.  in other cases, it identifies strange
situations like this:

===== RADIO_TEA5764_XTAL
drivers/media/radio/radio-tea5764.c:132:#ifndef RADIO_TEA5764_XTAL
drivers/media/radio/radio-tea5764.c:133:#define RADIO_TEA5764_XTAL 1
drivers/media/radio/radio-tea5764.c:137:static int use_xtal = RADIO_TEA5764_XTAL;
drivers/media/radio/Kconfig:412:config RADIO_TEA5764_XTAL

  in the above, what seems to be happening is that a Kconfig variable
is being defined and would lead the developer to think that it
represents something selectable, whereas the source file itself simply
hardcodes the equivalent value (or something like that).  that strikes
me as a recipe for confusion and potentially maddening debugging.

  also, over the course of today, i'll be updating the page of what i
call "badref" CONFIG variables -- variables that are being *tested*
but are not *defined* in any Kconfig file.  those have the potential
for more serious errors.  the current (unupdated) output for that is
here:

http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables

i'm betting a lot of that output isn't going to change even after
updating to the latest git tree.

rday
--



========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/