here's the next cleanup report that's well underway -- "bad"
references to CONFIG variables that don't exist in any Kconfig file:
http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables
(currently, only the arch/ and drivers/ directories have been updated
-- the rest should be done shortly.)
in a nutshell, that's a list of references to variables of the form
CONFIG_*, where there is no such variable defined anywhere in a
Kconfig file. some possible reasons for that:
1) leftover historical cruft
2) simple typo
3) someone's added code without adding the Kconfig infrastructure
for it (annoyingly, there appears to be quite a lot of that)
4) someone likes to name their macros with a "CONFIG_" prefix just
to pollute the Kconfig namespace (argh)
in any event, it's all there (some of it starting to look awfully
familiar as the years go by). as always, ignore the false positives.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
On Thu, Jun 25, 2009 at 10:34:05AM -0400, Robert P. J. Day wrote:
>
> here's the next cleanup report that's well underway -- "bad"
> references to CONFIG variables that don't exist in any Kconfig file:
>
> http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables
>
> (currently, only the arch/ and drivers/ directories have been updated
> -- the rest should be done shortly.)
>
> in a nutshell, that's a list of references to variables of the form
> CONFIG_*, where there is no such variable defined anywhere in a
> Kconfig file. some possible reasons for that:
>
> 1) leftover historical cruft
> 2) simple typo
> 3) someone's added code without adding the Kconfig infrastructure
> for it (annoyingly, there appears to be quite a lot of that)
> 4) someone likes to name their macros with a "CONFIG_" prefix just
> to pollute the Kconfig namespace (argh)
>
Care to send a patch to fix the one in arch/x86/include/asm/boot.h?
> in any event, it's all there (some of it starting to look awfully
> familiar as the years go by).
> as always, ignore the false positives.
If you continue this then please filter the know false positives.
For once start ignoring defconfigs.
Sam
On Thu, 25 Jun 2009, Sam Ravnborg wrote:
> If you continue this then please filter the know false positives.
> For once start ignoring defconfigs.
just to be clear, yes, there are numerous output lines from
defconfig files, but a simple entry in a defconfig file can never
*contribute* to something being flagged as bad or unused. all those
lines represent is the subsequent global search once something *has*
been flagged as unused or bad, just to show where it occurs anywhere
in the tree (which is sometimes informative).
if a variable occurred *only* in defconfig files, it would be
ignored and nothing would be printed for it. but if that defconfig
output has no value, i can toss it.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
On Thu, Jun 25, 2009 at 03:27:18PM -0400, Robert P. J. Day wrote:
> On Thu, 25 Jun 2009, Sam Ravnborg wrote:
>
> > If you continue this then please filter the know false positives.
> > For once start ignoring defconfigs.
>
> just to be clear, yes, there are numerous output lines from
> defconfig files, but a simple entry in a defconfig file can never
> *contribute* to something being flagged as bad or unused. all those
> lines represent is the subsequent global search once something *has*
> been flagged as unused or bad, just to show where it occurs anywhere
> in the tree (which is sometimes informative).
>
> if a variable occurred *only* in defconfig files, it would be
> ignored and nothing would be printed for it. but if that defconfig
> output has no value, i can toss it.
It only indicates that the defconfig is old.
And this is irellevant for this - so toss it.
Sam
On Thu, 25 Jun 2009, Sam Ravnborg wrote:
> If you continue this then please filter the know false positives.
> For once start ignoring defconfigs.
point taken. back at the "badrefs" page:
http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables
i've cleaned up the "arch" categories by removing all matches to
defconfig files, which cuts down the output considerably.
the "drivers" section will be cleaned similarly shortly.
rday
p.s. i did notice another false positive when the only references to
a "config" directive is nothing but other "select" directives. i'll
fix that one of these days. but it's never going to be perfect. law
of diminishing returns and all that.
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================