finding your own dead "CONFIG_" variables

finding your own dead "CONFIG_" variables

[Robert P. J. Day]

  while there's still a pile of possible dead CONFIG_ variables under
the fs/ and drivers/ directories i haven't posted yet, you don't need
to wait for me to generate them.  take a minute and run the script
yourself:

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

  a couple of examples:

$ ../dead_config.sh net/wanrouter
========== WANPIPE_MULTPPP ==========
net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP

$ ../dead_config.sh drivers/net/wireless
========== BCM947XX ==========
drivers/net/wireless/bcm43xx/bcm43xx_dma.c:663:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.h:36:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:64:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:145:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:789:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:799:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:1228:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:1390://FIXME: Do we _really_ want #ifndef CONFIG_BCM947XX here?
drivers/net/wireless/bcm43xx/bcm43xx_main.c:1392:#ifndef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:2143:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:2155:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:2648:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx_main.c:4147:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx.h:661:#ifdef CONFIG_BCM947XX
drivers/net/wireless/bcm43xx/bcm43xx.h:792:#ifdef CONFIG_BCM947XX
$

  go wild.

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

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

Re: finding your own dead "CONFIG_" variables

[Satyam Sharma]

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

> kcfiles=$(find . -name "Kconfig*")

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.

Re: finding your own dead "CONFIG_" variables

[Robert P. J. Day]

On Thu, 3 May 2007, Satyam Sharma wrote:

> > http://fsdev.net/wiki/index.php?title=Dead_CONFIG_variables
>
> > kcfiles=$(find . -name "Kconfig*")
>
> 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.

rday

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

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

Re: finding your own dead "CONFIG_" variables

[Arnd Bergmann]

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.

	Arnd <><

Re: finding your own dead "CONFIG_" variables

[Robert P. J. Day]

[-- 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
========================================================================