linux-kernel - Re: finding your own dead "CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0705030613120.32556@localhost.localdomain>
Date:	Thu, 3 May 2007 06:19:20 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Satyam Sharma <satyam.sharma@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org
Subject: Re: finding your own dead "CONFIG_" variables

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