]>
Commit | Line | Data |
---|---|---|
1 | Linux Kernel patch submission checklist | |
2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
3 | ||
4 | Here are some basic things that developers should do if they want to see their | |
5 | kernel patch submissions accepted more quickly. | |
6 | ||
7 | These are all above and beyond the documentation that is provided in | |
8 | Documentation/SubmittingPatches and elsewhere regarding submitting Linux | |
9 | kernel patches. | |
10 | ||
11 | ||
12 | 1: Builds cleanly with applicable or modified CONFIG options =y, =m, and | |
13 | =n. No gcc warnings/errors, no linker warnings/errors. | |
14 | ||
15 | 2: Passes allnoconfig, allmodconfig | |
16 | ||
17 | 3: Builds on multiple CPU architectures by using local cross-compile tools | |
18 | or something like PLM at OSDL. | |
19 | ||
20 | 4: ppc64 is a good architecture for cross-compilation checking because it | |
21 | tends to use `unsigned long' for 64-bit quantities. | |
22 | ||
23 | 5: Check your patch for general style as detailed in | |
24 | Documentation/CodingStyle. Check for trivial violations with the | |
25 | patch style checker prior to submission (scripts/checkpatch.pl). | |
26 | You should be able to justify all violations that remain in | |
27 | your patch. | |
28 | ||
29 | 6: Any new or modified CONFIG options don't muck up the config menu. | |
30 | ||
31 | 7: All new Kconfig options have help text. | |
32 | ||
33 | 8: Has been carefully reviewed with respect to relevant Kconfig | |
34 | combinations. This is very hard to get right with testing -- brainpower | |
35 | pays off here. | |
36 | ||
37 | 9: Check cleanly with sparse. | |
38 | ||
39 | 10: Use 'make checkstack' and 'make namespacecheck' and fix any problems | |
40 | that they find. Note: checkstack does not point out problems explicitly, | |
41 | but any one function that uses more than 512 bytes on the stack is a | |
42 | candidate for change. | |
43 | ||
44 | 11: Include kernel-doc to document global kernel APIs. (Not required for | |
45 | static functions, but OK there also.) Use 'make htmldocs' or 'make | |
46 | mandocs' to check the kernel-doc and fix any issues. | |
47 | ||
48 | 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, | |
49 | CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, | |
50 | CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously | |
51 | enabled. | |
52 | ||
53 | 13: Has been build- and runtime tested with and without CONFIG_SMP and | |
54 | CONFIG_PREEMPT. | |
55 | ||
56 | 14: If the patch affects IO/Disk, etc: has been tested with and without | |
57 | CONFIG_LBDAF. | |
58 | ||
59 | 15: All codepaths have been exercised with all lockdep features enabled. | |
60 | ||
61 | 16: All new /proc entries are documented under Documentation/ | |
62 | ||
63 | 17: All new kernel boot parameters are documented in | |
64 | Documentation/kernel-parameters.txt. | |
65 | ||
66 | 18: All new module parameters are documented with MODULE_PARM_DESC() | |
67 | ||
68 | 19: All new userspace interfaces are documented in Documentation/ABI/. | |
69 | See Documentation/ABI/README for more information. | |
70 | Patches that change userspace interfaces should be CCed to | |
71 | linux-api@vger.kernel.org. | |
72 | ||
73 | 20: Check that it all passes `make headers_check'. | |
74 | ||
75 | 21: Has been checked with injection of at least slab and page-allocation | |
76 | failures. See Documentation/fault-injection/. | |
77 | ||
78 | If the new code is substantial, addition of subsystem-specific fault | |
79 | injection might be appropriate. | |
80 | ||
81 | 22: Newly-added code has been compiled with `gcc -W' (use "make | |
82 | EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for | |
83 | finding bugs like "warning: comparison between signed and unsigned". | |
84 | ||
85 | 23: Tested after it has been merged into the -mm patchset to make sure | |
86 | that it still works with all of the other queued patches and various | |
87 | changes in the VM, VFS, and other subsystems. | |
88 | ||
89 | 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the | |
90 | source code that explains the logic of what they are doing and why. |