linux-kernel - checkpatch induced patches...

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]

Date:	Wed, 11 Feb 2015 10:00:29 -0800
From:	Joe Perches <joe@...ches.com>
To:	Dan Carpenter <dan.carpenter@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	devel@...verdev.osuosl.org, gmate.amit@...il.com,
	gregkh@...uxfoundation.org, Bas Peters <baspeters93@...il.com>,
	linux-kernel@...r.kernel.org,
	Pushpendra Singh <pushpendra.singh@...rtplayin.com>,
	manuel.schoelling@....de,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: checkpatch induced patches...

On Wed, 2015-02-11 at 13:51 +0300, Dan Carpenter wrote:
> On Wed, Feb 11, 2015 at 01:40:37AM -0800, Joe Perches wrote:
> > On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote:
> > > You can't fight checkpatch.pl.
> > 
> > Sure you can,  Ignore it whenever appropriate.
> 
> People will just keep sending patches until something gets merged.
> 
> It's rude to ignore patches and it's useless because people will just
> send another email asking you "have you received my patch yet?".  It
> just creates a bigger fight.

> Applying mediocre checkpatch cleanups takes less time and energy than
> constantly fighting.

Mediocre cleanup patches that fall into the
"not satisfactory, poor, inferior" category
shouldn't be applied.

> It's easiest to not fight over stupid stuff and
> just apply the patches.  Plus it makes the patch senders happy and
> that creates a happier community.

The primary thing I'd like to see stopped is the
use of checkpatch to satisfy some CS assignment.

Have any of those submitters ever gone on to produce
more thorough patches?

I'm half tempted to submit some patch like this to
make it difficult to use checkpatch on files outside
of drivers/staging.

o Only allow checkpatch to be used with the -f/--file
  option for drivers/staging/
o Add an undocumented --force command line option
o Make --strict the default for drivers/staging
---
 scripts/checkpatch.pl | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3642b0d..70f1047 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -25,6 +25,7 @@ my $tst_only;
 my $emacs = 0;
 my $terse = 0;
 my $file = 0;
+my $force = 0;
 my $check = 0;
 my $check_orig = 0;
 my $summary = 1;
@@ -130,6 +131,7 @@ GetOptions(
 	'emacs!'	=> \$emacs,
 	'terse!'	=> \$terse,
 	'f|file!'	=> \$file,
+	'force!'	=> \$force,
 	'subjective!'	=> \$check,
 	'strict!'	=> \$check,
 	'ignore=s'	=> \@ignore,
@@ -674,6 +676,10 @@ my $fixlinenr = -1;
 my $vname;
 for my $filename (@ARGV) {
 	my $FILE;
+	if (!$force && $file && $filename !~ m@...ivers/staging/@) {
+		warn "$P: checking '$filename' is not supported\n";
+		next;
+	}
 	if ($file) {
 		open($FILE, '-|', "diff -u /dev/null $filename") ||
 			die "$P: $filename: diff failed - $!\n";
@@ -2062,7 +2068,7 @@ sub process {
 		}
 
 		if ($found_file) {
-			if ($realfile =~ m@^(drivers/net/|net/)@) {
+			if ($realfile =~ m@^(?:drivers/net/|net/|drivers/staging/)@) {
 				$check = 1;
 			} else {
 				$check = $check_orig;



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