Messages in this thread | | | Date | Mon, 28 Dec 2009 06:55:00 -0500 (EST) | From | "Robert P. J. Day" <> | Subject | processing the unused and "badref" CONFIG variables |
| |
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 ========================================================================
| |