Commit 0a920b5b authored by Andy Whitcroft's avatar Andy Whitcroft Committed by Linus Torvalds

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: default avatarAndy Whitcroft <apw@shadowen.org>
Signed-off-by: default avatarJoel Schopp <jschopp@austin.ibm.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent bc913b18
...@@ -84,3 +84,9 @@ kernel patches. ...@@ -84,3 +84,9 @@ kernel patches.
24: Avoid whitespace damage such as indenting with spaces or whitespace 24: Avoid whitespace damage such as indenting with spaces or whitespace
at the end of lines. You can test this by feeding the patch to at the end of lines. You can test this by feeding the patch to
"git apply --check --whitespace=error-all" "git apply --check --whitespace=error-all"
25: Check your patch for general style as detailed in
Documentation/CodingStyle. Check for trivial violations with the
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
...@@ -118,7 +118,20 @@ then only post say 15 or so at a time and wait for review and integration. ...@@ -118,7 +118,20 @@ then only post say 15 or so at a time and wait for review and integration.
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 Look through the MAINTAINERS file and the source code, and determine
if your change applies to a specific subsystem of the kernel, with if your change applies to a specific subsystem of the kernel, with
...@@ -146,7 +159,7 @@ discussed should the patch then be submitted to Linus. ...@@ -146,7 +159,7 @@ discussed should the patch then be submitted to Linus.
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. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
...@@ -187,8 +200,7 @@ URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/> ...@@ -187,8 +200,7 @@ URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
7) No MIME, no links, no compression, no attachments. Just plain text.
6) No MIME, no links, no compression, no attachments. Just plain text.
Linus and other kernel developers need to be able to read and comment 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 on the changes you are submitting. It is important for a kernel
...@@ -223,9 +235,9 @@ pref("mailnews.display.disable_format_flowed_support", true); ...@@ -223,9 +235,9 @@ pref("mailnews.display.disable_format_flowed_support", true);
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 Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 40 kB in size, maintainers. If your patch, uncompressed, exceeds 40 kB in size,
...@@ -234,7 +246,7 @@ server, and provide instead a URL (link) pointing to your patch. ...@@ -234,7 +246,7 @@ server, and provide instead a URL (link) pointing to your patch.
8) Name your kernel version. 9) Name your kernel version.
It is important to note, either in the subject line or in the patch It is important to note, either in the subject line or in the patch
description, the kernel version to which this patch applies. description, the kernel version to which this patch applies.
...@@ -244,7 +256,7 @@ Linus will not apply it. ...@@ -244,7 +256,7 @@ Linus will not apply it.
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 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 likes your change and applies it, it will appear in the next version
...@@ -270,7 +282,7 @@ When in doubt, solicit comments on linux-kernel mailing list. ...@@ -270,7 +282,7 @@ When in doubt, solicit comments on linux-kernel mailing list.
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 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 convention to prefix your subject line with [PATCH]. This lets Linus
...@@ -279,7 +291,7 @@ e-mail discussions. ...@@ -279,7 +291,7 @@ e-mail discussions.
11) Sign your work 12) Sign your work
To improve tracking of who did what, especially with patches that can To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several percolate to their final resting place in the kernel through several
...@@ -328,7 +340,8 @@ now, but you can do this to mark internal company procedures or just ...@@ -328,7 +340,8 @@ now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off. 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: The canonical patch subject line is:
...@@ -427,6 +440,10 @@ section Linus Computer Science 101. ...@@ -427,6 +440,10 @@ section Linus Computer Science 101.
Nuff said. If your code deviates too much from this, it is likely Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment. 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 2) #ifdefs are ugly
......
...@@ -70,6 +70,7 @@ Who: David Miller <davem@davemloft.net> ...@@ -70,6 +70,7 @@ Who: David Miller <davem@davemloft.net>
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When: December 2006 When: December 2006
Files: include/linux/video_decoder.h
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
series. The old API have lots of drawbacks and don't provide enough series. The old API have lots of drawbacks and don't provide enough
means to work with all video and audio standards. The newer API is means to work with all video and audio standards. The newer API is
......
...@@ -30,8 +30,11 @@ trivial patch so apply some common sense. ...@@ -30,8 +30,11 @@ trivial patch so apply some common sense.
job the maintainers (and especially Linus) do is to keep things job the maintainers (and especially Linus) do is to keep things
looking the same. Sometimes this means that the clever hack in looking the same. Sometimes this means that the clever hack in
your driver to get around a problem actually needs to become a your driver to get around a problem actually needs to become a
generalized kernel feature ready for next time. See generalized kernel feature ready for next time.
Documentation/CodingStyle for guidance here.
PLEASE check your patch with the automated style checker
(scripts/checkpatch.pl) to catch trival style violations.
See Documentation/CodingStyle for guidance here.
PLEASE try to include any credit lines you want added with the PLEASE try to include any credit lines you want added with the
patch. It avoids people being missed off by mistake and makes patch. It avoids people being missed off by mistake and makes
...@@ -972,6 +975,15 @@ M: johannes@sipsolutions.net ...@@ -972,6 +975,15 @@ M: johannes@sipsolutions.net
L: linux-wireless@vger.kernel.org L: linux-wireless@vger.kernel.org
S: Maintained S: Maintained
CHECKPATCH
P: Andy Whitcroft
M: apw@shadowen.org
P: Randy Dunlap
M: rdunlap@xenotime.net
P: Joel Schopp
M: jschopp@austin.ibm.com
S: Supported
COMMON INTERNET FILE SYSTEM (CIFS) COMMON INTERNET FILE SYSTEM (CIFS)
P: Steve French P: Steve French
M: sfrench@samba.org M: sfrench@samba.org
......
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment