mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-24 02:18:54 +00:00
docs-rst: add inter-document cross references
Add cross references for the development process documents that were converted to ReST: Documentation/SubmitChecklist Documentation/SubmittingDrivers Documentation/SubmittingPatches Documentation/development-process/development-process.rst Documentation/stable_kernel_rules.txt Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Mauro Carvalho Chehab
Jonathan Corbet
parent
06ad636710
commit
dca22a63fd
@ -1,3 +1,5 @@
|
||||
.. _submitchecklist:
|
||||
|
||||
Linux Kernel patch submission checklist
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -5,7 +7,7 @@ Here are some basic things that developers should do if they want to see their
|
||||
kernel patch submissions accepted more quickly.
|
||||
|
||||
These are all above and beyond the documentation that is provided in
|
||||
Documentation/SubmittingPatches
|
||||
:ref:`Documentation/SubmittingPatches <submittingpatches>`
|
||||
and elsewhere regarding submitting Linux kernel patches.
|
||||
|
||||
|
||||
@ -28,8 +30,8 @@ and elsewhere regarding submitting Linux kernel patches.
|
||||
4) ppc64 is a good architecture for cross-compilation checking because it
|
||||
tends to use ``unsigned long`` for 64-bit quantities.
|
||||
|
||||
5: Check your patch for general style as detailed in
|
||||
Documentation/CodingStyle.
|
||||
5) Check your patch for general style as detailed in
|
||||
:ref:`Documentation/CodingStyle <codingstyle>`.
|
||||
Check for trivial violations with the patch style checker prior to
|
||||
submission (``scripts/checkpatch.pl``).
|
||||
You should be able to justify all violations that remain in
|
||||
@ -54,7 +56,7 @@ and elsewhere regarding submitting Linux kernel patches.
|
||||
but any one function that uses more than 512 bytes on the stack is a
|
||||
candidate for change.
|
||||
|
||||
11: Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs.
|
||||
11) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs.
|
||||
(Not required for static functions, but OK there also.) Use
|
||||
``make htmldocs`` or ``make pdfdocs`` to check the
|
||||
:ref:`kernel-doc <kernel_doc>` and fix any issues.
|
||||
|
||||
@ -40,9 +40,9 @@ Linux 2.4:
|
||||
maintainer does not respond or you cannot find the appropriate
|
||||
maintainer then please contact Willy Tarreau <w@1wt.eu>.
|
||||
|
||||
Linux 2.6:
|
||||
Linux 2.6 and upper:
|
||||
The same rules apply as 2.4 except that you should follow linux-kernel
|
||||
to track changes in API's. The final contact point for Linux 2.6
|
||||
to track changes in API's. The final contact point for Linux 2.6+
|
||||
submissions is Andrew Morton.
|
||||
|
||||
What Criteria Determine Acceptance
|
||||
@ -73,7 +73,8 @@ Interfaces:
|
||||
|
||||
Code:
|
||||
Please use the Linux style of code formatting as documented
|
||||
in Documentation/CodingStyle. If you have sections of code
|
||||
in :ref:`Documentation/CodingStyle <codingStyle>`.
|
||||
If you have sections of code
|
||||
that need to be in other formats, for example because they
|
||||
are shared with a windows driver kit and you want to
|
||||
maintain them just once separate them out nicely and note
|
||||
|
||||
@ -10,10 +10,12 @@ 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 Documentation/development-process. Also, read
|
||||
Documentation/SubmitChecklist for a list of items to check before
|
||||
works, see :ref:`Documentation/development-process <development_process_main>`.
|
||||
Also, read :ref:`Documentation/SubmitChecklist <submitchecklist>`
|
||||
for a list of items to check before
|
||||
submitting code. If you are submitting a driver, also read
|
||||
Documentation/SubmittingDrivers; for device tree binding patches, read
|
||||
:ref:`Documentation/SubmittingDrivers <submittingdrivers>`;
|
||||
for device tree binding patches, read
|
||||
Documentation/devicetree/bindings/submitting-patches.txt.
|
||||
|
||||
Many of these steps describe the default behavior of the ``git`` version
|
||||
@ -235,7 +237,9 @@ then only post say 15 or so at a time and wait for review and integration.
|
||||
---------------------------
|
||||
|
||||
Check your patch for basic style violations, details of which can be
|
||||
found in Documentation/CodingStyle. Failure to do so simply wastes
|
||||
found in
|
||||
:ref:`Documentation/CodingStyle <codingstyle>`.
|
||||
Failure to do so simply wastes
|
||||
the reviewers time and will get your patch rejected, probably
|
||||
without even being read.
|
||||
|
||||
@ -300,8 +304,9 @@ 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 Documentation/stable_kernel_rules.txt in addition to this
|
||||
file.
|
||||
should also read
|
||||
:ref:`Documentation/stable_kernel_rules.txt <stable_kernel_rules>`
|
||||
in addition to this file.
|
||||
|
||||
Note, however, that some subsystem maintainers want to come to their own
|
||||
conclusions on which patches should go to the stable trees. The networking
|
||||
@ -358,8 +363,9 @@ 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 Documentation/email-clients.txt for hints about configuring
|
||||
your e-mail client so that it sends your patches untouched.
|
||||
See :ref:`Documentation/email-clients.txt <email_clients>`
|
||||
for hints about configuring your e-mail client so that it sends your patches
|
||||
untouched.
|
||||
|
||||
7) E-mail size
|
||||
--------------
|
||||
@ -823,7 +829,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<Documentation/CodingStyle>
|
||||
:ref:`Documentation/CodingStyle <codingstyle>`
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _development_process_main:
|
||||
|
||||
A guide to the Kernel Development Process
|
||||
=========================================
|
||||
|
||||
|
||||
@ -26,7 +26,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the
|
||||
race can be exploited is also provided.
|
||||
- It cannot contain any "trivial" fixes in it (spelling changes,
|
||||
whitespace cleanups, etc).
|
||||
- It must follow the Documentation/SubmittingPatches rules.
|
||||
- It must follow the
|
||||
:ref:`Documentation/SubmittingPatches <submittingpatches>`
|
||||
rules.
|
||||
- It or an equivalent fix must already exist in Linus' tree (upstream).
|
||||
|
||||
|
||||
@ -37,7 +39,8 @@ Procedure for submitting patches to the -stable tree
|
||||
submission guidelines as described in
|
||||
Documentation/networking/netdev-FAQ.txt
|
||||
- Security patches should not be handled (solely) by the -stable review
|
||||
process but should follow the procedures in Documentation/SecurityBugs.
|
||||
process but should follow the procedures in
|
||||
:ref:`Documentation/SecurityBugs <securitybugs>`.
|
||||
|
||||
For all other submissions, choose one of the following procedures
|
||||
-----------------------------------------------------------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user