now that 2.6.25-rc1 is out, i can start updating the output from my
scanning scripts. the first updated output is the list of currently
unused Kconfig variables -- variables that are defined in some Kconfig
file somewhere but appear to be entirely unused throughout the source
tree.
latest output here, sorted by architecture:
http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
as always, there will probably be some false positives for one reason
or another.
output from the other scanning scripts will be up in short order.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
On Wed, Feb 13, 2008 at 03:56:34AM -0500, Robert P. J. Day wrote:
> latest output here, sorted by architecture:
>
> http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
>
> as always, there will probably be some false positives for one reason
> or another.
>
>>>>> SH_SDK7780_STANDALONE
arch/sh/boards/renesas/sdk7780/Kconfig:7:config SH_SDK7780_STANDALONE
is taken care of, thanks.
On Wed, 13 Feb 2008, Paul Mundt wrote:
> On Wed, Feb 13, 2008 at 03:56:34AM -0500, Robert P. J. Day wrote:
> > latest output here, sorted by architecture:
> >
> > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> >
> > as always, there will probably be some false positives for one reason
> > or another.
> >
>
> >>>>> SH_SDK7780_STANDALONE
> arch/sh/boards/renesas/sdk7780/Kconfig:7:config SH_SDK7780_STANDALONE
>
> is taken care of, thanks.
ok, i tossed it from the list.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
"Robert P. J. Day" <[email protected]> wrote:
>
> now that 2.6.25-rc1 is out, i can start updating the output from my
> scanning scripts. the first updated output is the list of currently
> unused Kconfig variables -- variables that are defined in some Kconfig
> file somewhere but appear to be entirely unused throughout the source
> tree.
>
> latest output here, sorted by architecture:
>
> http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
>
> as always, there will probably be some false positives for one reason
> or another.
>
> output from the other scanning scripts will be up in short order.
You have lots of false positives (or something) for arch/powerpc. Seems
your script picked up #define names and comments that happen to match a
Kconfig variable? And you have false positives on several CPU
variables, as they are used within Kconfig files themselves to select
different sets of options.
For arch/ppc, the WANT_EARLY_SERIAL stuff was added by Al to fix those
boards that unconditionally called early_serial_setup by selecting
SERIAL_8250 in commit f08243a491f3e21feabbb04476a03fb0cbc975ff. Al,
couldn't we just select SERIAL_8250 right in the board config
instead?
Of course, arch/ppc is dying soon-ish anyway so we might not even
bother.
josh
On Wed, 13 Feb 2008, Josh Boyer wrote:
> On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> "Robert P. J. Day" <[email protected]> wrote:
> > now that 2.6.25-rc1 is out, i can start updating the output from
> > my scanning scripts. the first updated output is the list of
> > currently unused Kconfig variables -- variables that are defined
> > in some Kconfig file somewhere but appear to be entirely unused
> > throughout the source tree.
> >
> > latest output here, sorted by architecture:
> >
> > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> >
> > as always, there will probably be some false positives for one
> > reason or another.
> >
> > output from the other scanning scripts will be up in short order.
>
> You have lots of false positives (or something) for arch/powerpc.
> Seems your script picked up #define names and comments that happen
> to match a Kconfig variable?
it always will, given the proclivity of some folks to define their own
variables with a "CONFIG_" prefix. as i point out on the wiki page, i
make no attempt to cull that list, i just print it as is, and readers
will have to peruse the list carefully to see what's meaningful and
what isn't.
> And you have false positives on several CPU variables, as they are
> used within Kconfig files themselves to select different sets of
> options.
yes, i know ... perhaps there's a simple way to filter those out but,
at the moment, it's pure brute force. i'm guessing i could make that
script a bit smarter but it probably isn't worth the investment in
time. law of diminishing returns and all that.
> For arch/ppc, the WANT_EARLY_SERIAL stuff was added by Al to fix those
> boards that unconditionally called early_serial_setup by selecting
> SERIAL_8250 in commit f08243a491f3e21feabbb04476a03fb0cbc975ff. Al,
> couldn't we just select SERIAL_8250 right in the board config
> instead?
>
> Of course, arch/ppc is dying soon-ish anyway so we might not even
> bother.
if that's the case, i can just stop scanning that entire directory.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
On Wed, Feb 13, 2008 at 10:07:27AM -0500, Robert P. J. Day wrote:
> On Wed, 13 Feb 2008, Josh Boyer wrote:
>
> > On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> > "Robert P. J. Day" <[email protected]> wrote:
>
> > > now that 2.6.25-rc1 is out, i can start updating the output from
> > > my scanning scripts. the first updated output is the list of
> > > currently unused Kconfig variables -- variables that are defined
> > > in some Kconfig file somewhere but appear to be entirely unused
> > > throughout the source tree.
> > >
> > > latest output here, sorted by architecture:
> > >
> > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> > >
> > > as always, there will probably be some false positives for one
> > > reason or another.
> > >
> > > output from the other scanning scripts will be up in short order.
> >
> > You have lots of false positives (or something) for arch/powerpc.
> > Seems your script picked up #define names and comments that happen
> > to match a Kconfig variable?
>
> it always will, given the proclivity of some folks to define their own
> variables with a "CONFIG_" prefix. as i point out on the wiki page, i
> make no attempt to cull that list, i just print it as is, and readers
> will have to peruse the list carefully to see what's meaningful and
> what isn't.
CONFIG_* should in the kernel be assumed a reserved namespace for kconifg.
So any use of variables/defines named CONFIG_* which is not a kconfig
symbol is a bug.
Sam
On Wed, 13 Feb 2008, Sam Ravnborg wrote:
> On Wed, Feb 13, 2008 at 10:07:27AM -0500, Robert P. J. Day wrote:
> > On Wed, 13 Feb 2008, Josh Boyer wrote:
> >
> > > On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> > > "Robert P. J. Day" <[email protected]> wrote:
> >
> > > > now that 2.6.25-rc1 is out, i can start updating the output from
> > > > my scanning scripts. the first updated output is the list of
> > > > currently unused Kconfig variables -- variables that are defined
> > > > in some Kconfig file somewhere but appear to be entirely unused
> > > > throughout the source tree.
> > > >
> > > > latest output here, sorted by architecture:
> > > >
> > > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> > > >
> > > > as always, there will probably be some false positives for one
> > > > reason or another.
> > > >
> > > > output from the other scanning scripts will be up in short order.
> > >
> > > You have lots of false positives (or something) for arch/powerpc.
> > > Seems your script picked up #define names and comments that happen
> > > to match a Kconfig variable?
> >
> > it always will, given the proclivity of some folks to define their own
> > variables with a "CONFIG_" prefix. as i point out on the wiki page, i
> > make no attempt to cull that list, i just print it as is, and readers
> > will have to peruse the list carefully to see what's meaningful and
> > what isn't.
>
> CONFIG_* should in the kernel be assumed a reserved namespace for
> kconifg. So any use of variables/defines named CONFIG_* which is not
> a kconfig symbol is a bug.
heh ... good luck with *that*:
$ grep -r "^#define CONFIG_" * | wc -l
752
$
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
On Wed, 13 Feb 2008 10:07:27 -0500 (EST)
"Robert P. J. Day" <[email protected]> wrote:
> On Wed, 13 Feb 2008, Josh Boyer wrote:
>
> > On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> > "Robert P. J. Day" <[email protected]> wrote:
>
> > > now that 2.6.25-rc1 is out, i can start updating the output from
> > > my scanning scripts. the first updated output is the list of
> > > currently unused Kconfig variables -- variables that are defined
> > > in some Kconfig file somewhere but appear to be entirely unused
> > > throughout the source tree.
> > >
> > > latest output here, sorted by architecture:
> > >
> > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> > >
> > > as always, there will probably be some false positives for one
> > > reason or another.
> > >
> > > output from the other scanning scripts will be up in short order.
> >
> > You have lots of false positives (or something) for arch/powerpc.
> > Seems your script picked up #define names and comments that happen
> > to match a Kconfig variable?
>
> it always will, given the proclivity of some folks to define their own
> variables with a "CONFIG_" prefix. as i point out on the wiki page, i
> make no attempt to cull that list, i just print it as is, and readers
> will have to peruse the list carefully to see what's meaningful and
> what isn't.
OK. Well all of your hits for 405EX, 440GRX, 440SPe, and
WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune
those when reported or not.
> > And you have false positives on several CPU variables, as they are
> > used within Kconfig files themselves to select different sets of
> > options.
>
> yes, i know ... perhaps there's a simple way to filter those out but,
> at the moment, it's pure brute force. i'm guessing i could make that
> script a bit smarter but it probably isn't worth the investment in
> time. law of diminishing returns and all that.
Maybe. If the same false positives keep showing up people might ignore
it. I won't, but others might.
> > For arch/ppc, the WANT_EARLY_SERIAL stuff was added by Al to fix those
> > boards that unconditionally called early_serial_setup by selecting
> > SERIAL_8250 in commit f08243a491f3e21feabbb04476a03fb0cbc975ff. Al,
> > couldn't we just select SERIAL_8250 right in the board config
> > instead?
> >
> > Of course, arch/ppc is dying soon-ish anyway so we might not even
> > bother.
>
> if that's the case, i can just stop scanning that entire directory.
It's going away in June, per feature-removal-schedule. I will still fix
actual bugs until then, but not much else.
josh
On Wed, 13 Feb 2008, Josh Boyer wrote:
> OK. Well all of your hits for 405EX, 440GRX, 440SPe, and
> WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune
> those when reported or not.
not normally, but i don't know what you mean by "bogus":
$ grep -r "config 405EX" *
arch/powerpc/platforms/40x/Kconfig:config 405EX
$
$ grep -r CONFIG_405EX *
arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y
arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y
$
so, AFAICT, there exists a definition of the Kconfig variable 405EX,
which is subsequently not referenced *anywhere* in the tree except in
a couple defconfig files, which don't count. how, then, does that
Kconfig variable have any practical value? or am i missing something
painfully obvious?
> > > And you have false positives on several CPU variables, as they
> > > are used within Kconfig files themselves to select different
> > > sets of options.
> >
> > yes, i know ... perhaps there's a simple way to filter those out
> > but, at the moment, it's pure brute force. i'm guessing i could
> > make that script a bit smarter but it probably isn't worth the
> > investment in time. law of diminishing returns and all that.
>
> Maybe. If the same false positives keep showing up people might
> ignore it. I won't, but others might.
fair enough, but since this scanning happens only once every release,
it's not like it's a burden. and if people want to ignore it, that's
fine, too.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
On Wed, Feb 13, 2008 at 10:44:27AM -0500, Robert P. J. Day wrote:
> On Wed, 13 Feb 2008, Josh Boyer wrote:
>
> > OK. Well all of your hits for 405EX, 440GRX, 440SPe, and
> > WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune
> > those when reported or not.
>
> not normally, but i don't know what you mean by "bogus":
>
> $ grep -r "config 405EX" *
> arch/powerpc/platforms/40x/Kconfig:config 405EX
> $
>
> $ grep -r CONFIG_405EX *
> arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y
> arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y
> $
$ git grep 405EX | grep select
arch/powerpc/platforms/40x/Kconfig: select 405EX
arch/powerpc/platforms/40x/Kconfig: select 405EX
So it is used.
Sam
On Wed, 13 Feb 2008, Sam Ravnborg wrote:
> On Wed, Feb 13, 2008 at 10:44:27AM -0500, Robert P. J. Day wrote:
> > On Wed, 13 Feb 2008, Josh Boyer wrote:
> >
> > > OK. Well all of your hits for 405EX, 440GRX, 440SPe, and
> > > WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune
> > > those when reported or not.
> >
> > not normally, but i don't know what you mean by "bogus":
> >
> > $ grep -r "config 405EX" *
> > arch/powerpc/platforms/40x/Kconfig:config 405EX
> > $
> >
> > $ grep -r CONFIG_405EX *
> > arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y
> > arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y
> > $
>
> $ git grep 405EX | grep select
> arch/powerpc/platforms/40x/Kconfig: select 405EX
> arch/powerpc/platforms/40x/Kconfig: select 405EX
>
> So it is used.
ok, i see the flaw in my logic. the Kconfig variable 405EX isn't
tested *directly* by anyone, it's simply used to further "select"
other variables, which my script doesn't take into account.
config 405EX
bool
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
i don't think i'm quite ready to add that logic to a simple scanning
script.
oh, well.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================