linux-kernel - Re: even *more* unused CONFIG variables at no extra charge

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 19 Nov 2007 08:57:09 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Paul Mundt <lethal@...ux-sh.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: even *more* unused CONFIG variables at no extra charge

On Mon, 19 Nov 2007, Paul Mundt wrote:

> On Fri, Nov 16, 2007 at 06:15:48AM -0500, Robert P. J. Day wrote:
> > ==== sh64 ====
> > >>>>> DEVICE_MEMORY_START
> > >>>>> FLASH_MEMORY_START
> > >>>>> HDSP253_LED
> > >>>>> PCI_BLOCK_START
> > >>>>> PCIDEVICE_MEMORY_START
>
> Yeah, these are mostly bogus and just never got removed. I'll poke
> through it and kill them off or fix up the Makefiles to actually use
> them (as in the HDSP253_LED case). Thanks for catching these, these
> sorts of reports are really useful.
>
> Have you considered tidying up your config checker and adding it as
> a static analyser target with the existing set? 'make configcheck'
> or something would be a reasonable addition.

i've thought about that but, really, i doubt it's worth it for a
couple reasons.  first is that this sort of cleanup isn't what you'd
call life or death.  it's rare that dealing with any of this output
actually fixes a bug -- it's mostly for aesthetics so even i'll be the
first to admit that it's not high priority.

also, some of those checks take a looooooooong time.  i mean, we're
talking *hours* as each CONFIG variable might invoke a tree-wide grep.
you don't start some of these checks and go for coffee; you start some
of them and drive into toronto for a leafs game, if you catch my
drift.

and it's not like you need to run these checks on a really regular
basis.  i've come to realize it's sufficient to do the entire suite
shortly after each merge window, post the results, and let people take
it from there until the next merge window.  in between, it's not like
things are going to change drastically.

however, having said all that, one thing that would make a *huge*
difference in reducing false positives is if people would stop naming
their hard-coded Makefile variables with a "CONFIG_" prefix.  man,
that's irritating.  :-)

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

http://crashcourse.ca
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/