Re: finding your own dead "CONFIG_" variables

["Robert P. J. Day" <rpjday@mindspring.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1831 bytes --]

On Thu, 3 May 2007, Arnd Bergmann wrote:

> On Thursday 03 May 2007, Robert P. J. Day wrote:
> > > Suggest: configfiles=$(find . -name 'Kconfig*' -or -name '*defconfig*')
> > >
> > > Some CONFIG_ options exist that are not declared anywhere in the
> > > Kconfig files but defined directly in the arch/.../*defconfig*
> > > files.
> >
> > it's my understanding that entries in any defconfig files are
> > *automatically* pruned at some point once a CONFIG_ variable no longer
> > exists in any Kconfig file, so i'm not going to be touching those
> > files.  also, adding that extra check wouldn't add anything useful to
> > the output.
>
>
> An interesting category would be a symbol that is
>
> - used in a source file
> - defined in an old defconfig
> - not present in any Kconfig* file
>
> If any of these exist, I would consider them _worse_ than the ones
> found by your initial script, because some functionality that once
> was there has been recently removed.

hmmmmmm ... i see your point now -- not present in any Kconfig file
but still being selected by a defconfig file that might still be
affecting the eventual build.  that's an easy enough change to make
but, as i've mentioned before, this output could be reduced
substantially if developers stopped using CONFIG_ prefixed macro names
for their own non-Kconfig variables (*cough* MTD *cough* :-).

but, again, some of that issue might disappear if those defconfig
files were auto-regenerated on a timely basis (if that is, in fact,
how they're kept up to date).

rday

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================