diff options
Diffstat (limited to 'Documentation/process')
| -rw-r--r-- | Documentation/process/4.Coding.rst | 6 | ||||
| -rw-r--r-- | Documentation/process/submit-checklist.rst | 24 | ||||
| -rw-r--r-- | Documentation/process/submitting-patches.rst | 8 |
3 files changed, 21 insertions, 17 deletions
diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index c27e59d2f702..0825dc496f22 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -249,10 +249,8 @@ features; most of these are found in the "kernel hacking" submenu. Several of these options should be turned on for any kernel used for development or testing purposes. In particular, you should turn on: - - ENABLE_MUST_CHECK and FRAME_WARN to get an - extra set of warnings for problems like the use of deprecated interfaces - or ignoring an important return value from a function. The output - generated by these warnings can be verbose, but one need not worry about + - FRAME_WARN to get warnings for stack frames larger than a given amount. + The output generated can be verbose, but one need not worry about warnings from other parts of the kernel. - DEBUG_OBJECTS will add code to track the lifetime of various objects diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index 1879f881c300..230ee42f872f 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -75,44 +75,44 @@ and elsewhere regarding submitting Linux kernel patches. 13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and ``CONFIG_PREEMPT.`` -16) All codepaths have been exercised with all lockdep features enabled. +14) All codepaths have been exercised with all lockdep features enabled. -17) All new ``/proc`` entries are documented under ``Documentation/`` +15) All new ``/proc`` entries are documented under ``Documentation/`` -18) All new kernel boot parameters are documented in +16) All new kernel boot parameters are documented in ``Documentation/admin-guide/kernel-parameters.rst``. -19) All new module parameters are documented with ``MODULE_PARM_DESC()`` +17) All new module parameters are documented with ``MODULE_PARM_DESC()`` -20) All new userspace interfaces are documented in ``Documentation/ABI/``. +18) All new userspace interfaces are documented in ``Documentation/ABI/``. See ``Documentation/ABI/README`` for more information. Patches that change userspace interfaces should be CCed to linux-api@vger.kernel.org. -21) Check that it all passes ``make headers_check``. +19) Check that it all passes ``make headers_check``. -22) Has been checked with injection of at least slab and page-allocation +20) Has been checked with injection of at least slab and page-allocation failures. See ``Documentation/fault-injection/``. If the new code is substantial, addition of subsystem-specific fault injection might be appropriate. -23) Newly-added code has been compiled with ``gcc -W`` (use +21) 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". -24) Tested after it has been merged into the -mm patchset to make sure +22) 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 changes in the VM, VFS, and other subsystems. -25) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a +23) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a comment in the source code that explains the logic of what they are doing and why. -26) If any ioctl's are added by the patch, then also update +24) If any ioctl's are added by the patch, then also update ``Documentation/userspace-api/ioctl/ioctl-number.rst``. -27) If your modified source code depends on or uses any of the kernel +25) If your modified source code depends on or uses any of the kernel APIs or features that are related to the following ``Kconfig`` symbols, then test multiple builds with the related ``Kconfig`` symbols disabled and/or ``=m`` (if that option is available) [not all of these at the diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index fb8261a4be30..5ba54120bef7 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -411,6 +411,12 @@ Some people also put extra tags at the end. They'll just be ignored for now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. +Any further SoBs (Signed-off-by:'s) following the author's SoB are from +people handling and transporting the patch, but were not involved in its +development. SoB chains should reflect the **real** route a patch took +as it was propagated to the maintainers and ultimately to Linus, with +the first SoB entry signalling primary authorship of a single author. + When to use Acked-by:, Cc:, and Co-developed-by: ------------------------------------------------ @@ -446,7 +452,7 @@ patch. This tag documents that potentially interested parties have been included in the discussion. Co-developed-by: states that the patch was co-created by multiple developers; -it is a used to give attribution to co-authors (in addition to the author +it is used to give attribution to co-authors (in addition to the author attributed by the From: tag) when several people work on a single patch. Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author. Standard sign-off |