diff options
Diffstat (limited to 'Documentation/process')
| -rw-r--r-- | Documentation/process/applying-patches.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/deprecated.rst | 4 | ||||
| -rw-r--r-- | Documentation/process/kernel-docs.rst | 14 | ||||
| -rw-r--r-- | Documentation/process/maintainer-pgp-guide.rst | 14 | ||||
| -rw-r--r-- | Documentation/process/submitting-patches.rst | 42 |
5 files changed, 37 insertions, 39 deletions
diff --git a/Documentation/process/applying-patches.rst b/Documentation/process/applying-patches.rst index 2e7017bef4b8..c2121c1e55d7 100644 --- a/Documentation/process/applying-patches.rst +++ b/Documentation/process/applying-patches.rst @@ -389,7 +389,7 @@ The -mm patches are experimental patches released by Andrew Morton. In the past, -mm tree were used to also test subsystem patches, but this function is now done via the -`linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>` +`linux-next` (https://www.kernel.org/doc/man-pages/linux-next.html) tree. The Subsystem maintainers push their patches first to linux-next, and, during the merge window, sends them directly to Linus. diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 9d83b8db8874..8ced754a5a0f 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -164,7 +164,9 @@ Paraphrasing Linus's current `guidance <https://lore.kernel.org/lkml/CA+55aFwQEd up to Linus's scrutiny, maybe you can use "%px", along with making sure you have sensible permissions. -And finally, know that a toggle for "%p" hashing will `not be accepted <https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_. +If you are debugging something where "%p" hashing is causing problems, +you can temporarily boot with the debug flag "`no_hash_pointers +<https://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6>`_". Variable Length Arrays (VLAs) ----------------------------- diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 22d9ace5df2a..da9527502ef0 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -126,15 +126,17 @@ On-line docs describes how to write user-mode utilities for communicating with Card Services. - * Title: **Linux Kernel Module Programming Guide** + * Title: **The Linux Kernel Module Programming Guide** - :Author: Ori Pomerantz. - :URL: https://tldp.org/LDP/lkmpg/2.6/html/index.html - :Date: 2001 + :Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, + Jim Huang. + :URL: https://sysprog21.github.io/lkmpg/ + :Date: 2021 :Keywords: modules, GPL book, /proc, ioctls, system calls, interrupt handlers . - :Description: Very nice 92 pages GPL book on the topic of modules - programming. Lots of examples. + :Description: A very nice GPL book on the topic of modules + programming. Lots of examples. Currently the new version is being + actively maintained at https://github.com/sysprog21/lkmpg. * Title: **Global spinlock list and usage** diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst index 8f8f1fee92b8..29e7d7b1cd44 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -944,12 +944,11 @@ have on your keyring:: uid [ unknown] Linus Torvalds <torvalds@kernel.org> sub rsa2048 2011-09-20 [E] -Next, open the `PGP pathfinder`_. In the "From" field, paste the key -fingerprint of Linus Torvalds from the output above. In the "To" field, -paste the key-id you found via ``gpg --search`` of the unknown key, and -check the results: - -- `Finding paths to Linus`_ +Next, find a trust path from Linus Torvalds to the key-id you found via ``gpg +--search`` of the unknown key. For this, you can use several tools including +https://github.com/mricon/wotmate, +https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, and +https://the.earth.li/~noodles/pathfind.html. If you get a few decent trust paths, then it's a pretty good indication that it is a valid key. You can add it to your keyring from the @@ -962,6 +961,3 @@ administrators of the PGP Pathfinder service to not be malicious (in fact, this goes against :ref:`devs_not_infra`). However, if you do not carefully maintain your own web of trust, then it is a marked improvement over blindly trusting keyservers. - -.. _`PGP pathfinder`: https://pgp.cs.uu.nl/ -.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index c66a19201deb..8ad6b93f91e6 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -10,10 +10,11 @@ can greatly increase the chances of your change being accepted. This document contains a large number of suggestions in a relatively terse format. For detailed information on how the kernel development process -works, see :doc:`development-process`. Also, read :doc:`submit-checklist` +works, see Documentation/process/development-process.rst. Also, read +Documentation/process/submit-checklist.rst for a list of items to check before submitting code. If you are submitting -a driver, also read :doc:`submitting-drivers`; for device tree binding patches, -read :doc:`submitting-patches`. +a driver, also read Documentation/process/submitting-drivers.rst; for device +tree binding patches, read Documentation/process/submitting-patches.rst. This documentation assumes that you're using ``git`` to prepare your patches. If you're unfamiliar with ``git``, you would be well-advised to learn how to @@ -178,8 +179,7 @@ Style-check your changes ------------------------ Check your patch for basic style violations, details of which can be -found in -:ref:`Documentation/process/coding-style.rst <codingstyle>`. +found in Documentation/process/coding-style.rst. Failure to do so simply wastes the reviewers time and will get your patch rejected, probably without even being read. @@ -216,11 +216,11 @@ cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. You should also normally choose at least one mailing list to receive a copy -of your patch set. linux-kernel@vger.kernel.org functions as a list of -last resort, but the volume on that list has caused a number of developers -to tune it out. Look in the MAINTAINERS file for a subsystem-specific -list; your patch will probably get more attention there. Please do not -spam unrelated lists, though. +of your patch set. linux-kernel@vger.kernel.org should be used by default +for all patches, but the volume on that list has caused a number of +developers to tune it out. Look in the MAINTAINERS file for a +subsystem-specific list; your patch will probably get more attention there. +Please do not spam unrelated lists, though. Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are @@ -238,7 +238,7 @@ If you have a patch that fixes an exploitable security bug, send that patch to security@kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also -:doc:`/admin-guide/security-bugs`. +Documentation/admin-guide/security-bugs.rst. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:: @@ -246,9 +246,8 @@ toward the stable maintainers by putting a line like this:: Cc: stable@vger.kernel.org into the sign-off area of your patch (note, NOT an email recipient). You -should also read -:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` -in addition to this file. +should also read Documentation/process/stable-kernel-rules.rst +in addition to this document. If changes affect userland-kernel interfaces, please send the MAN-PAGES maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at @@ -305,8 +304,8 @@ decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. -See :doc:`/process/email-clients` for hints about configuring your e-mail -client so that it sends your patches untouched. +See Documentation/process/email-clients.rst for hints about configuring +your e-mail client so that it sends your patches untouched. Respond to review comments -------------------------- @@ -324,7 +323,7 @@ for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out. -See :doc:`email-clients` for recommendations on email +See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. @@ -562,10 +561,10 @@ method for indicating a bug fixed by the patch. See :ref:`describe_changes` for more details. Note: Attaching a Fixes: tag does not subvert the stable kernel rules -process nor the requirement to Cc: stable@vger.kernel.org on all stable +process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates. For more information, please read -:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` - +Documentation/process/stable-kernel-rules.rst. + .. _the_canonical_patch_format: The canonical patch format @@ -824,8 +823,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> -Kernel Documentation/process/coding-style.rst: - :ref:`Documentation/process/coding-style.rst <codingstyle>` +Kernel Documentation/process/coding-style.rst Linus Torvalds's mail on the canonical patch format: <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org> |