linux-kernel - Re: how to properly post/disseminate kernel cleanup/janitorial possibilities?

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: <alpine.LFD.2.00.0904290938310.5304@localhost.localdomain>
Date:	Wed, 29 Apr 2009 09:44:53 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Jiri Kosina <jkosina@...e.cz>
cc:	hannes@...xchg.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: how to properly post/disseminate kernel cleanup/janitorial
 possibilities?

On Wed, 29 Apr 2009, Jiri Kosina wrote:

> On Tue, 28 Apr 2009, Robert P. J. Day wrote:
>
> > > > Perhaps Jiri can pick up some of the patches that remove stale
> > > > config symbols, correct typos etc.

> > > Absolutely. I'll happily apply anything trivial enough (typo fixes,
> > > removal of obviously unused symbols/config options, etc).

> > the *problem* is that, sometimes, it's not obvious.  as in, when a
> > Kconfig file has a pile of unused config options but it turns out
> > that those were added for future consideration to match up with
> > code that hasn't been added yet and the subsystem maintainer knows
> > about it but wants it to stay (IMHO, a really bad idea -- adding
> > kernel features in incomplete pieces, but whatever).
>
> Hmm ... do you have any particular outstanding examples of this?

  historically, plenty, based on the number of times i've submitted
patches to various maintainers to remove unused symbols, only to be
told that those symbols were added in a preliminary fashion, and the
accompanying code should be along any day now.  obviously, that
doesn't cause any actual problems but it certainly messes up the
history of a feature by breaking its introduction over more than one
patch.

  and as for *current* examples, well, there's this page:

http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables

one recent example was MAC80211_VERBOSE_SPECT_MGMT_DEBUG, if you
wanted an actual reference.

  really, i'm *aware* that 99% of this scanning and cleanup is benign.
but that final 1% sometimes really does represent a bug and, since i
have the scripts and it's pretty much free to run them whenever i
want, we're back to the original question -- what's the best venue to
distribute this info so as not to bore to tears the people who don't
care about it?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Linked In:                             http://www.linkedin.com/in/rpjday
Twitter:                                       http://twitter.com/rpjday
========================================================================
--
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/