Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit dca22a63 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet
Browse files

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: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 06ad6367

Documentation/SubmitChecklist

+6 −4
Original line number Original line Diff line number Diff line 
.. _submitchecklist:



Linux Kernel patch submission checklist

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.

kernel patch submissions accepted more quickly.





These are all above and beyond the documentation that is provided in

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.

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

4) ppc64 is a good architecture for cross-compilation checking because it

   tends to use ``unsigned long`` for 64-bit quantities.

   tends to use ``unsigned long`` for 64-bit quantities.





5: Check your patch for general style as detailed in

5) Check your patch for general style as detailed in

   Documentation/CodingStyle.

   :ref:`Documentation/CodingStyle <codingstyle>`.

   Check for trivial violations with the patch style checker prior to

   Check for trivial violations with the patch style checker prior to

   submission (``scripts/checkpatch.pl``).

   submission (``scripts/checkpatch.pl``).

   You should be able to justify all violations that remain in

   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

       but any one function that uses more than 512 bytes on the stack is a

       candidate for change.

       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

    (Not required for static functions, but OK there also.) Use

    ``make htmldocs`` or ``make pdfdocs`` to check the

    ``make htmldocs`` or ``make pdfdocs`` to check the

    :ref:`kernel-doc <kernel_doc>` and fix any issues.

    :ref:`kernel-doc <kernel_doc>` and fix any issues.

Documentation/SubmittingDrivers

+4 −3
Original line number Original line Diff line number Diff line
@@ -40,9 +40,9 @@ Linux 2.4: 
	maintainer does not respond or you cannot find the appropriate

	maintainer does not respond or you cannot find the appropriate

	maintainer then please contact Willy Tarreau <w@1wt.eu>.

	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

	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.

	submissions is Andrew Morton.





What Criteria Determine Acceptance

What Criteria Determine Acceptance
@@ -73,7 +73,8 @@ Interfaces: 




Code:

Code:

		Please use the Linux style of code formatting as documented

		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

		that need to be in other formats, for example because they

		are shared with a windows driver kit and you want to

		are shared with a windows driver kit and you want to

		maintain them just once separate them out nicely and note

		maintain them just once separate them out nicely and note

Documentation/SubmittingPatches

+15 −9
Original line number Original line Diff line number Diff line
@@ -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

This document contains a large number of suggestions in a relatively terse

format.  For detailed information on how the kernel development process

format.  For detailed information on how the kernel development process

works, see Documentation/development-process.  Also, read

works, see :ref:`Documentation/development-process <development_process_main>`.

Documentation/SubmitChecklist for a list of items to check before

Also, read :ref:`Documentation/SubmitChecklist <submitchecklist>`

for a list of items to check before

submitting code.  If you are submitting a driver, also read

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.

Documentation/devicetree/bindings/submitting-patches.txt.





Many of these steps describe the default behavior of the ``git`` version

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

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

the reviewers time and will get your patch rejected, probably

without even being read.

without even being read.
@@ -300,8 +304,9 @@ toward the stable maintainers by putting a line like this:: 
  Cc: stable@vger.kernel.org

  Cc: stable@vger.kernel.org





into the sign-off area of your patch (note, NOT an email recipient).  You

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

should also read

file.

: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

Note, however, that some subsystem maintainers want to come to their own

conclusions on which patches should go to the stable trees.  The networking

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

Exception:  If your mailer is mangling patches then someone may ask

you to re-send them using MIME.

you to re-send them using MIME.





See Documentation/email-clients.txt for hints about configuring

See :ref:`Documentation/email-clients.txt <email_clients>`

your e-mail client so that it sends your patches untouched.

for hints about configuring your e-mail client so that it sends your patches

untouched.





7) E-mail size

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>

  <https://lkml.org/lkml/2005/7/11/336>





Kernel Documentation/CodingStyle:

Kernel Documentation/CodingStyle:

  <Documentation/CodingStyle>

  :ref:`Documentation/CodingStyle <codingstyle>`





Linus Torvalds's mail on the canonical patch format:

Linus Torvalds's mail on the canonical patch format:

  <http://lkml.org/lkml/2005/4/7/183>

  <http://lkml.org/lkml/2005/4/7/183>

Documentation/development-process/development-process.rst

+2 −0
Original line number Original line Diff line number Diff line 
.. _development_process_main:



A guide to the Kernel Development Process

A guide to the Kernel Development Process

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

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

Documentation/stable_kernel_rules.txt

+5 −2
Original line number Original line Diff line number Diff line
@@ -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.

   race can be exploited is also provided.

 - It cannot contain any "trivial" fixes in it (spelling changes,

 - It cannot contain any "trivial" fixes in it (spelling changes,

   whitespace cleanups, etc).

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

 - 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

   submission guidelines as described in

   Documentation/networking/netdev-FAQ.txt

   Documentation/networking/netdev-FAQ.txt

 - Security patches should not be handled (solely) by the -stable review

 - 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

For all other submissions, choose one of the following procedures

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

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