Re: even *more* unused CONFIG variables at no extra charge

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Mon, 19 Nov 2007, Paul Mundt wrote:

> On Fri, Nov 16, 2007 at 06:15:48AM -0500, Robert P. J. Day wrote:
> > ==== sh64 ====
> > >>>>> DEVICE_MEMORY_START
> > >>>>> FLASH_MEMORY_START
> > >>>>> HDSP253_LED
> > >>>>> PCI_BLOCK_START
> > >>>>> PCIDEVICE_MEMORY_START
>
> Yeah, these are mostly bogus and just never got removed. I'll poke
> through it and kill them off or fix up the Makefiles to actually use
> them (as in the HDSP253_LED case). Thanks for catching these, these
> sorts of reports are really useful.
>
> Have you considered tidying up your config checker and adding it as
> a static analyser target with the existing set? 'make configcheck'
> or something would be a reasonable addition.

i've thought about that but, really, i doubt it's worth it for a
couple reasons.  first is that this sort of cleanup isn't what you'd
call life or death.  it's rare that dealing with any of this output
actually fixes a bug -- it's mostly for aesthetics so even i'll be the
first to admit that it's not high priority.

also, some of those checks take a looooooooong time.  i mean, we're
talking *hours* as each CONFIG variable might invoke a tree-wide grep.
you don't start some of these checks and go for coffee; you start some
of them and drive into toronto for a leafs game, if you catch my
drift.

and it's not like you need to run these checks on a really regular
basis.  i've come to realize it's sufficient to do the entire suite
shortly after each merge window, post the results, and let people take
it from there until the next merge window.  in between, it's not like
things are going to change drastically.

however, having said all that, one thing that would make a *huge*
difference in reducing false positives is if people would stop naming
their hard-coded Makefile variables with a "CONFIG_" prefix.  man,
that's irritating.  :-)

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================