| 1 | .. _submitchecklist: |
| 2 | |
| 3 | Linux Kernel patch submission checklist |
| 4 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 5 | |
| 6 | Here are some basic things that developers should do if they want to see their |
| 7 | kernel patch submissions accepted more quickly. |
| 8 | |
| 9 | These are all above and beyond the documentation that is provided in |
| 10 | :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` |
| 11 | and elsewhere regarding submitting Linux kernel patches. |
| 12 | |
| 13 | |
| 14 | 1) If you use a facility then #include the file that defines/declares |
| 15 | that facility. Don't depend on other header files pulling in ones |
| 16 | that you use. |
| 17 | |
| 18 | 2) Builds cleanly: |
| 19 | |
| 20 | a) with applicable or modified ``CONFIG`` options ``=y``, ``=m``, and |
| 21 | ``=n``. No ``gcc`` warnings/errors, no linker warnings/errors. |
| 22 | |
| 23 | b) Passes ``allnoconfig``, ``allmodconfig`` |
| 24 | |
| 25 | c) Builds successfully when using ``O=builddir`` |
| 26 | |
| 27 | 3) Builds on multiple CPU architectures by using local cross-compile tools |
| 28 | or some other build farm. |
| 29 | |
| 30 | 4) ppc64 is a good architecture for cross-compilation checking because it |
| 31 | tends to use ``unsigned long`` for 64-bit quantities. |
| 32 | |
| 33 | 5) Check your patch for general style as detailed in |
| 34 | :ref:`Documentation/process/coding-style.rst <codingstyle>`. |
| 35 | Check for trivial violations with the patch style checker prior to |
| 36 | submission (``scripts/checkpatch.pl``). |
| 37 | You should be able to justify all violations that remain in |
| 38 | your patch. |
| 39 | |
| 40 | 6) Any new or modified ``CONFIG`` options do not muck up the config menu and |
| 41 | default to off unless they meet the exception criteria documented in |
| 42 | ``Documentation/kbuild/kconfig-language.txt`` Menu attributes: default value. |
| 43 | |
| 44 | 7) All new ``Kconfig`` options have help text. |
| 45 | |
| 46 | 8) Has been carefully reviewed with respect to relevant ``Kconfig`` |
| 47 | combinations. This is very hard to get right with testing -- brainpower |
| 48 | pays off here. |
| 49 | |
| 50 | 9) Check cleanly with sparse. |
| 51 | |
| 52 | 10) Use ``make checkstack`` and ``make namespacecheck`` and fix any problems |
| 53 | that they find. |
| 54 | |
| 55 | .. note:: |
| 56 | |
| 57 | ``checkstack`` does not point out problems explicitly, |
| 58 | but any one function that uses more than 512 bytes on the stack is a |
| 59 | candidate for change. |
| 60 | |
| 61 | 11) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs. |
| 62 | (Not required for static functions, but OK there also.) Use |
| 63 | ``make htmldocs`` or ``make pdfdocs`` to check the |
| 64 | :ref:`kernel-doc <kernel_doc>` and fix any issues. |
| 65 | |
| 66 | 12) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, |
| 67 | ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, |
| 68 | ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, |
| 69 | ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` all |
| 70 | simultaneously enabled. |
| 71 | |
| 72 | 13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and |
| 73 | ``CONFIG_PREEMPT.`` |
| 74 | |
| 75 | 14) If the patch affects IO/Disk, etc: has been tested with and without |
| 76 | ``CONFIG_LBDAF.`` |
| 77 | |
| 78 | 15) All codepaths have been exercised with all lockdep features enabled. |
| 79 | |
| 80 | 16) All new ``/proc`` entries are documented under ``Documentation/`` |
| 81 | |
| 82 | 17) All new kernel boot parameters are documented in |
| 83 | ``Documentation/admin-guide/kernel-parameters.rst``. |
| 84 | |
| 85 | 18) All new module parameters are documented with ``MODULE_PARM_DESC()`` |
| 86 | |
| 87 | 19) All new userspace interfaces are documented in ``Documentation/ABI/``. |
| 88 | See ``Documentation/ABI/README`` for more information. |
| 89 | Patches that change userspace interfaces should be CCed to |
| 90 | linux-api@vger.kernel.org. |
| 91 | |
| 92 | 20) Check that it all passes ``make headers_check``. |
| 93 | |
| 94 | 21) Has been checked with injection of at least slab and page-allocation |
| 95 | failures. See ``Documentation/fault-injection/``. |
| 96 | |
| 97 | If the new code is substantial, addition of subsystem-specific fault |
| 98 | injection might be appropriate. |
| 99 | |
| 100 | 22) Newly-added code has been compiled with ``gcc -W`` (use |
| 101 | ``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good |
| 102 | for finding bugs like "warning: comparison between signed and unsigned". |
| 103 | |
| 104 | 23) Tested after it has been merged into the -mm patchset to make sure |
| 105 | that it still works with all of the other queued patches and various |
| 106 | changes in the VM, VFS, and other subsystems. |
| 107 | |
| 108 | 24) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a |
| 109 | comment in the source code that explains the logic of what they are doing |
| 110 | and why. |
| 111 | |
| 112 | 25) If any ioctl's are added by the patch, then also update |
| 113 | ``Documentation/ioctl/ioctl-number.txt``. |
| 114 | |
| 115 | 26) If your modified source code depends on or uses any of the kernel |
| 116 | APIs or features that are related to the following ``Kconfig`` symbols, |
| 117 | then test multiple builds with the related ``Kconfig`` symbols disabled |
| 118 | and/or ``=m`` (if that option is available) [not all of these at the |
| 119 | same time, just various/random combinations of them]: |
| 120 | |
| 121 | ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, |
| 122 | ``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``). |