not sure when i'll get the time to do another pass over the kernel
source tree with my kernel cleanup scripts but anyone who's
interested is welcome to download the scripts from here:
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
to check out whatever part of the tree they want.
as a simple example, i can run the script to find "badref" config
variables on, say, the drivers/mtd part of the tree:
$ ../s/find_badref_configs.sh drivers/mtd
>>>>> MTD_SUPERH_RESERVE
drivers/mtd/maps/solutionengine.c:38:#ifdef CONFIG_MTD_SUPERH_RESERVE
drivers/mtd/maps/solutionengine.c:44: .size = CONFIG_MTD_SUPERH_RESERVE,
drivers/mtd/maps/solutionengine.c:54:#endif /* CONFIG_MTD_SUPERH_RESERVE */
drivers/mtd/maps/solutionengine.c:97:#ifdef CONFIG_MTD_SUPERH_RESERVE
drivers/mtd/maps/solutionengine.c:100: CONFIG_MTD_SUPERH_RESERVE);
drivers/mtd/maps/solutionengine.c:104:#endif /* CONFIG_MTD_SUPERH_RESERVE */
$
that tells me that, under drivers/mtd, there's some file that
insists on testing CONFIG_MTD_SUPERH_RESERVE even though no Kconfig
file defines such a variable.
the other common check is to look for the exact opposite --
variables defined in a Kconfig file that are never tested anywhere.
once again, let's pick on drivers/mtd:
$ ../s/find_unused_configs.sh drivers/mtd
===== MTD_NAND_ATMEL_ECC_SOFT
drivers/mtd/nand/Kconfig:375:config MTD_NAND_ATMEL_ECC_SOFT
$
that should be self-explanatory. anyway, have at it if it interests
you.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
CC the mtd maintainer and mailinglist and adjusted subject. Robert, you
should report such bugs to the maintainer / author of the code in
question, otherwise your mail might end up unnoticed on LKML.
Michal
On 9.11.2010 13:16, Robert P. J. Day wrote:
>
> not sure when i'll get the time to do another pass over the kernel
> source tree with my kernel cleanup scripts but anyone who's
> interested is welcome to download the scripts from here:
>
> http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
>
> to check out whatever part of the tree they want.
>
> as a simple example, i can run the script to find "badref" config
> variables on, say, the drivers/mtd part of the tree:
>
> $ ../s/find_badref_configs.sh drivers/mtd
>>>>>> MTD_SUPERH_RESERVE
> drivers/mtd/maps/solutionengine.c:38:#ifdef CONFIG_MTD_SUPERH_RESERVE
> drivers/mtd/maps/solutionengine.c:44: .size = CONFIG_MTD_SUPERH_RESERVE,
> drivers/mtd/maps/solutionengine.c:54:#endif /* CONFIG_MTD_SUPERH_RESERVE */
> drivers/mtd/maps/solutionengine.c:97:#ifdef CONFIG_MTD_SUPERH_RESERVE
> drivers/mtd/maps/solutionengine.c:100: CONFIG_MTD_SUPERH_RESERVE);
> drivers/mtd/maps/solutionengine.c:104:#endif /* CONFIG_MTD_SUPERH_RESERVE */
> $
>
> that tells me that, under drivers/mtd, there's some file that
> insists on testing CONFIG_MTD_SUPERH_RESERVE even though no Kconfig
> file defines such a variable.
>
> the other common check is to look for the exact opposite --
> variables defined in a Kconfig file that are never tested anywhere.
> once again, let's pick on drivers/mtd:
>
> $ ../s/find_unused_configs.sh drivers/mtd
> ===== MTD_NAND_ATMEL_ECC_SOFT
> drivers/mtd/nand/Kconfig:375:config MTD_NAND_ATMEL_ECC_SOFT
> $
>
> that should be self-explanatory. anyway, have at it if it interests
> you.
>
> rday
>
>
On Thu, 25 Nov 2010, Michal Marek wrote:
> CC the mtd maintainer and mailinglist and adjusted subject. Robert, you
> should report such bugs to the maintainer / author of the code in
> question, otherwise your mail might end up unnoticed on LKML.
>
> Michal
{sigh}. the point of my earlier post was not specifically to point
out unused kernel config vars in the MTD code; rather, it was to
suggest that anyone who's interested can run my scanning scripts to
locate such things for themselves in their favourite subsystem(s) -- i
simply used the MTD code as a working example.
and, BTW, there are still dead config variables in the code that go
back *several* major versions, even though i've documented them just
as many times here:
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup
so if you're curious, the scripts are here:
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
On 26.11.2010 17:29, Robert P. J. Day wrote:
> and, BTW, there are still dead config variables in the code that go
> back *several* major versions, even though i've documented them just
> as many times here:
>
> http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup
That might be the problem - that you are document the bugs in your wiki,
instead of sending reports to the maintainers directly :).
Michal
On Fri, 26 Nov 2010, Michal Marek wrote:
> On 26.11.2010 17:29, Robert P. J. Day wrote:
> > and, BTW, there are still dead config variables in the code that go
> > back *several* major versions, even though i've documented them just
> > as many times here:
> >
> > http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup
>
> That might be the problem - that you are document the bugs in your
> wiki, instead of sending reports to the maintainers directly :).
yes, the obvious problem here is that i clearly haven't been putting
enough effort into this. i'll keep that in mind.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================