diff options
Diffstat (limited to 'Documentation/process')
| -rw-r--r-- | Documentation/process/clang-format.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/embargoed-hardware-issues.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/howto.rst | 9 | ||||
| -rw-r--r-- | Documentation/process/kernel-docs.rst | 4 | ||||
| -rw-r--r-- | Documentation/process/magic-number.rst | 1 | ||||
| -rw-r--r-- | Documentation/process/stable-kernel-rules.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/submit-checklist.rst | 24 | ||||
| -rw-r--r-- | Documentation/process/submitting-patches.rst | 10 |
8 files changed, 30 insertions, 24 deletions
diff --git a/Documentation/process/clang-format.rst b/Documentation/process/clang-format.rst index 82676e5a7c6e..1d089a847c1b 100644 --- a/Documentation/process/clang-format.rst +++ b/Documentation/process/clang-format.rst @@ -97,7 +97,7 @@ it can be very useful. There are integrations for many popular text editors. For some of them, like vim, emacs, BBEdit and Visual Studio you can find support built-in. -For instructions, read the appropiate section at: +For instructions, read the appropriate section at: https://clang.llvm.org/docs/ClangFormat.html diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index 43cdc67e4f8e..6f8f36e10e8b 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -152,7 +152,7 @@ The disclosing party should provide a list of contacts for all other entities who have already been, or should be, informed about the issue. This serves several purposes: - - The list of disclosed entities allows communication accross the + - The list of disclosed entities allows communication across the industry, e.g. other OS vendors, HW vendors, etc. - The disclosed entities can be contacted to name experts who should diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 20c9e07e09a4..7a5c105e34d4 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -348,11 +348,10 @@ tool. For details on how to use the kernel bugzilla, please see: https://bugzilla.kernel.org/page.cgi?id=faq.html -The file :ref:`admin-guide/reporting-bugs.rst <reportingbugs>` -in the main kernel source directory has a good -template for how to report a possible kernel bug, and details what kind -of information is needed by the kernel developers to help track down the -problem. +The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel +source directory has a good template for how to report a possible kernel bug, +and details what kind of information is needed by the kernel developers to help +track down the problem. Managing bug reports diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 64786e50026c..22d9ace5df2a 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -90,7 +90,7 @@ On-line docs :Date: 2008 :Keywords: patches, review process, types of submissions, basic rules, case studies :Description: This paper gives several experience values on what types of patches - there are and how likley they get merged. + there are and how likely they get merged. :Abstract: [...]. This paper examines some common problems for submitting larger changes and some strategies to avoid problems. @@ -328,7 +328,7 @@ On-line docs block devices, hardware interrupts, scsi, DMA, access to user memory, memory allocation, timers. :Description: A guide designed to help you get up to speed on the - concepts that are not intuitevly obvious, and to document the internal + concepts that are not intuitively obvious, and to document the internal structures of Linux. * Title: **Dynamic Kernels: Modularized Device Drivers** diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst index eee9b44553b3..e02ff5ffb653 100644 --- a/Documentation/process/magic-number.rst +++ b/Documentation/process/magic-number.rst @@ -84,7 +84,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 06f743b612c4..3973556250e1 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree submission guidelines as described in :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>` after first checking the stable networking queue at - https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= + https://patchwork.kernel.org/bundle/netdev/stable/?state=* to ensure the requested patch is not already queued up. - Security patches should not be handled (solely) by the -stable review process but should follow the procedures in 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 83d9a82055a7..5ba54120bef7 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -404,11 +404,19 @@ then you just add a line saying:: using your real name (sorry, no pseudonyms or anonymous contributions.) This will be done for you automatically if you use ``git commit -s``. +Reverts should also include "Signed-off-by". ``git revert -s`` does that +for you. 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: ------------------------------------------------ @@ -444,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 |