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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0904280619590.16989@localhost.localdomain>
Date:	Tue, 28 Apr 2009 06:31:14 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Jiri Kosina <jkosina@...e.cz>
cc:	Johannes Weiner <hannes@...xchg.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: how to properly post/disseminate kernel cleanup/janitorial
 possibilities?

On Tue, 28 Apr 2009, Jiri Kosina wrote:

> On Tue, 28 Apr 2009, Johannes Weiner wrote:
>
> > > long story short, i have a *pile* of scripts and sub-scripts i'm
> > > happy to run and post the results of since it takes practically
> > > zero time on my part, i'm just open to what folks think is the
> > > most productive way to do that, and also for any other scanning
> > > i can add since, by now, any other patterns to scan for would
> > > just represent adding a line or two to a script.
> > >  thoughts?

> > Yes.  I wonder why you take the time to generate the output and
> > email it but then stop there instead of just sending patches?
> >
> > grep -A5 TRIVIAL MAINTAINERS
> >
> > 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).

  in any event, my only point is that, sometimes, only the subsystem
maintainer really knows how to resolve something that *looks*
trivially resolvable or removable.  IIRC, a simple observation on the
unused symbols HAVE_READQ and HAVE_WRITEQ sparked a lengthy discussion
that would never have happened if the "obvious" deletion on those
symbols had been done.

  the right thing to do is not always obvious.

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/