docs-rst: add inter-document cross references

.. _submitchecklist:

Linux Kernel patch submission checklist

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

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

       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.

	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

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

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

---------------------------

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.

  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

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

--------------

  <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>

.. _development_process_main:

A guide to the Kernel Development Process

=========================================

   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).

   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

-----------------------------------------------------------------