1 Linux Kernel patch sumbittal checklist
2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 Here are some basic things that developers should do if they
5 want to see their kernel patch submittals accepted quicker.
7 These are all above and beyond the documentation that is provided
8 in Documentation/SubmittingPatches and elsewhere about submitting
13 - Builds cleanly with applicable or modified CONFIG options =y, =m, and =n.
14 No gcc warnings/errors, no linker warnings/errors.
16 - Passes allnoconfig, allmodconfig
18 - Builds on multiple CPU arch-es by using local cross-compile tools
19 or something like PLM at OSDL.
21 - ppc64 is a good architecture for cross-compilation checking because it
22 tends to use `unsigned long' for 64-bit quantities.
24 - Matches kernel coding style(!)
26 - Any new or modified CONFIG options don't muck up the config menu.
28 - All new Kconfig options have help text.
30 - Has been carefully reviewed with respect to relevant Kconfig
31 combinations. This is very hard to get right with testing --
32 brainpower pays off here.
34 - Check cleanly with sparse.
36 - Use 'make checkstack' and 'make namespacecheck' and fix any
37 problems that they find. Note: checkstack does not point out
38 problems explicitly, but any one function that uses more than
39 512 bytes on the stack is a candidate for change.
41 - Include kernel-doc to document global kernel APIs. (Not required
42 for static functions, but OK there also.) Use 'make htmldocs'
43 or 'make mandocs' to check the kernel-doc and fix any issues.
45 - Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
46 CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
47 CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
50 - Has been build- and runtime tested with and without CONFIG_SMP and
53 - If the patch affects IO/Disk, etc: has been tested with and without