X-Git-Url: https://git.karo-electronics.de/?a=blobdiff_plain;f=Documentation%2FSubmitChecklist;h=34e06d2f194fe58f082743a9407e670c442b9d85;hb=185c045c245f46485ad8bbd8cc1100e986ff3f13;hp=6491b2c45dd48af654e411278559d537ec237330;hpb=ba7cc09c9c9e29a57045dc5bbf843ac1cfad3283;p=mv-sheeva.git diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index 6491b2c45dd..34e06d2f194 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -1,4 +1,4 @@ -Linux Kernel patch sumbittal checklist +Linux Kernel patch submission checklist ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here are some basic things that developers should do if they want to see their @@ -9,7 +9,6 @@ Documentation/SubmittingPatches and elsewhere regarding submitting Linux kernel patches. - 1: Builds cleanly with applicable or modified CONFIG options =y, =m, and =n. No gcc warnings/errors, no linker warnings/errors. @@ -68,14 +67,14 @@ kernel patches. 20: Check that it all passes `make headers_check'. 21: Has been checked with injection of at least slab and page-allocation - fauilures. See Documentation/fault-injection/. + failures. See Documentation/fault-injection/. If the new code is substantial, addition of subsystem-specific fault injection might be appropriate. -22: Newly-added code has been compiled with `gcc -W'. This will generate - lots of noise, but is good for finding bugs like "warning: comparison - between signed and unsigned". +22: Newly-added code has been compiled with `gcc -W' (use "make + EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for + finding bugs like "warning: comparison between signed and unsigned". 23: Tested after it has been merged into the -mm patchset to make sure that it still works with all of the other queued patches and various @@ -84,3 +83,9 @@ kernel patches. 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 "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.