linux-kernel - Re: [PATCH] Deprecate checkpatch.pl --file

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]

Message-Id: <1199829059.12972.40.camel@imap.mvista.com>
Date:	Tue, 08 Jan 2008 13:50:59 -0800
From:	Daniel Walker <dwalker@...sta.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Sam Ravnborg <sam@...nborg.org>, Andi Kleen <andi@...stfloor.org>,
	linux-kernel@...r.kernel.org, apw@...dowen.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] Deprecate checkpatch.pl --file

On Tue, 2008-01-08 at 16:14 -0500, Theodore Tso wrote:
> On Tue, Jan 08, 2008 at 12:19:44PM -0800, Daniel Walker wrote:
> > > But is discourage the creation of pure clean-up patches because it
> > > may have a disturbing effect on several other peoples work.
> > 
> > pure clean ups are _good_ patches , are they not?
> > 
> 
> Not necessarily.  Whether or not it is requires common sense, and very
> often we get enthusiastic new-comers (some of them with very weak C
> programming skills :-) who might try to use checkpatch.pl.  So we
> can't assume that they will know when a pure clean-up patch is a good
> thing, and when it's a waste of everyone's time, including theirs.

You can pretty much generalize this to many patches on many mailing
lists.. Someone submits a patch that they didn't think about, and ..
It's at least a learning experience for the person submitting the patch.
It does however seem a lot less likely someone will screw up a change
when checkpatch.pl actually tells you the line where the style problem
is, and what it is .. Even with "WARNING" and "ERROR" classifications.

> That's why I think the warning is a good thing.  It makes it more
> likely that this gets communicated to the enthusiastic, well-meaning,
> newcomer.  Someone who is more experienced and who knows how to
> determine whether some driver is ancient and not being worked on, and
> hence a pure clean-up patch won't be screwing up other developers,
> will know how to suppress the warning.  (OTOH, how important is it in
> the grand scheem of things to create or apply a pure clean-up patch on
> a patch that few people if any are looking at?)

There is a maintainer involved in all this .. The maintainer needs to
accept the patch prior to it "... screwing up other developers." Given a
sane maintainer, and a sane list review then why wouldn't a pure clean
up be accepted?

The warning message is actually an end run around the maintainer.. The
clean up never gets created, and the maintainer doesn't have the choice
to include it or not.. 

Daniel

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