Documentation/SubmitChecklist

   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: Matches kernel coding style(!)
  24
  25 6: Any new or modified CONFIG options don't muck up the config menu.
  26
  27 7: All new Kconfig options have help text.
  28
  29 8: Has been carefully reviewed with respect to relevant Kconfig
  30    combinations.  This is very hard to get right with testing -- brainpower
  31    pays off here.
  32
  33 9: Check cleanly with sparse.
  34
  35 10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
  36     that they find.  Note: checkstack does not point out problems explicitly,
  37     but any one function that uses more than 512 bytes on the stack is a
  38     candidate for change.
  39
  40 11: Include kernel-doc to document global kernel APIs.  (Not required for
  41     static functions, but OK there also.) Use 'make htmldocs' or 'make
  42     mandocs' to check the kernel-doc and fix any issues.
  43
  44 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
  45     CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
  46     CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
  47     enabled.
  48
  49 13: Has been build- and runtime tested with and without CONFIG_SMP and
  50     CONFIG_PREEMPT.
  51
  52 14: If the patch affects IO/Disk, etc: has been tested with and without
  53     CONFIG_LBD.
  54
  55 15: All codepaths have been exercised with all lockdep features enabled.
  56
  57 16: All new /proc entries are documented under Documentation/
  58
  59 17: All new kernel boot parameters are documented in
  60     Documentation/kernel-parameters.txt.
  61
  62 18: All new module parameters are documented with MODULE_PARM_DESC()
  63
  64 19: All new userspace interfaces are documented in Documentation/ABI/.
  65     See Documentation/ABI/README for more information.
  66
  67 20: Check that it all passes `make headers_check'.
  68
  69 21: Has been checked with injection of at least slab and page-allocation
  70     failures.  See Documentation/fault-injection/.
  71
  72     If the new code is substantial, addition of subsystem-specific fault
  73     injection might be appropriate.
  74
  75 22: Newly-added code has been compiled with `gcc -W' (use "make
  76     EXTRA_CFLAGS=-W").  This will generate lots of noise, but is good for
  77     finding bugs like "warning: comparison between signed and unsigned".
  78
  79 23: Tested after it has been merged into the -mm patchset to make sure
  80     that it still works with all of the other queued patches and various
  81     changes in the VM, VFS, and other subsystems.
  82
  83 24: Avoid whitespace damage such as indenting with spaces or whitespace
  84     at the end of lines.  You can test this by feeding the patch to
  85     "git apply --check --whitespace=error-all"
  86
  87 25: Check your patch for general style as detailed in
  88     Documentation/CodingStyle.  Check for trivial violations with the
  89     patch style checker prior to submission (scripts/checkpatch.pl).
  90     You should be able to justify all violations that remain in
  91     your patch.