add a trivial patch style checker
We are seeing increasing levels of minor patch style violations in submissions
to the mailing lists as well as making it into the tree. These detract from
the quality of the submission and cause unnessary work for reviewers.
As a first step package up the current state of the patch style checker and
include it in the kernel tree. Add instructions suggesting running it on
submissions. This adds version v0.01 of the checkpatch.pl script.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index a417b25..d91125a 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -118,7 +118,20 @@
-4) Select e-mail destination.
+4) Style check your changes.
+
+Check your patch for basic style violations, details of which can be
+found in Documentation/CodingStyle. Failure to do so simply wastes
+the reviewers time and will get your patch rejected, probabally
+without even being read.
+
+At a minimum you should check your patches with the patch style
+checker prior to submission (scripts/patchcheck.pl). You should
+be able to justify all violations that remain in your patch.
+
+
+
+5) Select e-mail destination.
Look through the MAINTAINERS file and the source code, and determine
if your change applies to a specific subsystem of the kernel, with
@@ -146,7 +159,7 @@
-5) Select your CC (e-mail carbon copy) list.
+6) Select your CC (e-mail carbon copy) list.
Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
@@ -187,8 +200,7 @@
-
-6) No MIME, no links, no compression, no attachments. Just plain text.
+7) No MIME, no links, no compression, no attachments. Just plain text.
Linus and other kernel developers need to be able to read and comment
on the changes you are submitting. It is important for a kernel
@@ -223,9 +235,9 @@
-7) E-mail size.
+8) E-mail size.
-When sending patches to Linus, always follow step #6.
+When sending patches to Linus, always follow step #7.
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 40 kB in size,
@@ -234,7 +246,7 @@
-8) Name your kernel version.
+9) Name your kernel version.
It is important to note, either in the subject line or in the patch
description, the kernel version to which this patch applies.
@@ -244,7 +256,7 @@
-9) Don't get discouraged. Re-submit.
+10) Don't get discouraged. Re-submit.
After you have submitted your change, be patient and wait. If Linus
likes your change and applies it, it will appear in the next version
@@ -270,7 +282,7 @@
-10) Include PATCH in the subject
+11) Include PATCH in the subject
Due to high e-mail traffic to Linus, and to linux-kernel, it is common
convention to prefix your subject line with [PATCH]. This lets Linus
@@ -279,7 +291,7 @@
-11) Sign your work
+12) Sign your work
To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
@@ -328,7 +340,8 @@
point out some special detail about the sign-off.
-12) The canonical patch format
+
+13) The canonical patch format
The canonical patch subject line is:
@@ -427,6 +440,10 @@
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
+Check your patches with the patch style checker prior to submission
+(scripts/checkpatch.pl). You should be able to justify all
+violations that remain in your patch.
+
2) #ifdefs are ugly