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
+the reviewers time and will get your patch rejected, probably
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
+checker prior to submission (scripts/checkpatch.pl). You should
be able to justify all violations that remain in your patch.
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
-Once significant exception is when moving code from one file to
-another in this case you should not modify the moved code at all in
+One significant exception is when moving code from one file to
+another -- in this case you should not modify the moved code at all in
the same patch which moves it. This clearly delineates the act of
moving the code and your changes. This greatly aids review of the
actual differences and allows tools to better track the history of
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
Kernel Documentation/CodingStyle:
- <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
+ <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>