diff options
Diffstat (limited to 'Documentation/process')
| -rw-r--r-- | Documentation/process/4.Coding.rst | 3 | ||||
| -rw-r--r-- | Documentation/process/5.Posting.rst | 23 | ||||
| -rw-r--r-- | Documentation/process/8.Conclusion.rst | 7 | ||||
| -rw-r--r-- | Documentation/process/changes.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/coding-style.rst | 2 | ||||
| -rw-r--r-- | Documentation/process/howto.rst | 11 | ||||
| -rw-r--r-- | Documentation/process/management-style.rst | 5 | ||||
| -rw-r--r-- | Documentation/process/submitting-drivers.rst | 8 |
8 files changed, 35 insertions, 26 deletions
diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index eb4b185d168c..cfe264889447 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -315,7 +315,8 @@ variety of potential coding problems; it can also propose fixes for those problems. Quite a few "semantic patches" for the kernel have been packaged under the scripts/coccinelle directory; running "make coccicheck" will run through those semantic patches and report on any problems found. See -Documentation/dev-tools/coccinelle.rst for more information. +:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>` +for more information. Other kinds of portability errors are best found by compiling your code for other architectures. If you do not happen to have an S/390 system or a diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index c418c5d6cae4..4213e580f273 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -9,9 +9,10 @@ kernel. Unsurprisingly, the kernel development community has evolved a set of conventions and procedures which are used in the posting of patches; following them will make life much easier for everybody involved. This document will attempt to cover these expectations in reasonable detail; -more information can also be found in the files process/submitting-patches.rst, -process/submitting-drivers.rst, and process/submit-checklist.rst in the kernel -documentation directory. +more information can also be found in the files +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`, +:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` +and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`. When to post @@ -198,8 +199,10 @@ pass it to diff with the "-X" option. The tags mentioned above are used to describe how various developers have been associated with the development of this patch. They are described in -detail in the process/submitting-patches.rst document; what follows here is a -brief summary. Each of these lines has the format: +detail in +the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` +document; what follows here is a brief summary. Each of these lines has +the format: :: @@ -210,8 +213,8 @@ The tags in common use are: - Signed-off-by: this is a developer's certification that he or she has the right to submit the patch for inclusion into the kernel. It is an agreement to the Developer's Certificate of Origin, the full text of - which can be found in Documentation/process/submitting-patches.rst. Code - without a proper signoff cannot be merged into the mainline. + which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` + Code without a proper signoff cannot be merged into the mainline. - Co-developed-by: states that the patch was also created by another developer along with the original author. This is useful at times when multiple @@ -226,7 +229,7 @@ The tags in common use are: it to work. - Reviewed-by: the named developer has reviewed the patch for correctness; - see the reviewer's statement in Documentation/process/submitting-patches.rst + see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` for more detail. - Reported-by: names a user who reported a problem which is fixed by this @@ -253,8 +256,8 @@ take care of: be examined in any detail. If there is any doubt at all, mail the patch to yourself and convince yourself that it shows up intact. - Documentation/process/email-clients.rst has some helpful hints on making - specific mail clients work for sending patches. + :ref:`Documentation/process/email-clients.rst <email_clients>` has some + helpful hints on making specific mail clients work for sending patches. - Are you sure your patch is free of silly mistakes? You should always run patches through scripts/checkpatch.pl and address the complaints it diff --git a/Documentation/process/8.Conclusion.rst b/Documentation/process/8.Conclusion.rst index 1c7f54cd0261..8395aa2c1f3a 100644 --- a/Documentation/process/8.Conclusion.rst +++ b/Documentation/process/8.Conclusion.rst @@ -5,9 +5,10 @@ For more information There are numerous sources of information on Linux kernel development and related topics. First among those will always be the Documentation -directory found in the kernel source distribution. The top-level process/howto.rst -file is an important starting point; process/submitting-patches.rst and -process/submitting-drivers.rst are also something which all kernel developers should +directory found in the kernel source distribution. The top-level :ref:`process/howto.rst <process_howto>` +file is an important starting point; :ref:`process/submitting-patches.rst <submittingpatches>` +and :ref:`process/submitting-drivers.rst <submittingdrivers>` +are also something which all kernel developers should read. Many internal kernel APIs are documented using the kerneldoc mechanism; "make htmldocs" or "make pdfdocs" can be used to generate those documents in HTML or PDF format (though the version of TeX shipped by some diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index d1bf143b446f..18735dc460a0 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -326,7 +326,7 @@ Kernel documentation Sphinx ------ -Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst`` +Please see :ref:`sphinx_install` in :ref:`Documentation/doc-guide/sphinx.rst <sphinxdoc>` for details about Sphinx requirements. Getting updated software diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 4e7c0a1c427a..277c113376a6 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -1075,5 +1075,5 @@ gcc internals and indent, all available from http://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ -Kernel process/coding-style.rst, by greg@kroah.com at OLS 2002: +Kernel :ref:`process/coding-style.rst <codingstyle>`, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index a4a9f9eb0dd8..58b2f46c4f98 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -298,9 +298,9 @@ two weeks, but it can be longer if there are no pressing problems. A security-related problem, instead, can cause a release to happen almost instantly. -The file Documentation/process/stable-kernel-rules.rst in the kernel tree -documents what kinds of changes are acceptable for the -stable tree, and -how the release process works. +The file :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` +in the kernel tree documents what kinds of changes are acceptable for +the -stable tree, and how the release process works. 4.x -git patches ~~~~~~~~~~~~~~~~ @@ -360,7 +360,8 @@ tool. For details on how to use the kernel bugzilla, please see: https://bugzilla.kernel.org/page.cgi?id=faq.html -The file admin-guide/reporting-bugs.rst in the main kernel source directory has a good +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. @@ -426,7 +427,7 @@ add your statements between the individual quoted sections instead of writing at the top of the mail. If you add patches to your mail, make sure they are plain readable text -as stated in Documentation/process/submitting-patches.rst. +as stated in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`. Kernel developers don't want to deal with attachments or compressed patches; they may want to comment on individual lines of your patch, which works only that way. Make sure you diff --git a/Documentation/process/management-style.rst b/Documentation/process/management-style.rst index 85ef8ca8f639..186753ff3d2d 100644 --- a/Documentation/process/management-style.rst +++ b/Documentation/process/management-style.rst @@ -5,8 +5,9 @@ Linux kernel management style This is a short document describing the preferred (or made up, depending on who you ask) management style for the linux kernel. It's meant to -mirror the process/coding-style.rst document to some degree, and mainly written to -avoid answering [#f1]_ the same (or similar) questions over and over again. +mirror the :ref:`process/coding-style.rst <codingstyle>` document to some +degree, and mainly written to avoid answering [#f1]_ the same (or similar) +questions over and over again. Management style is very personal and much harder to quantify than simple coding style rules, so this document may or may not have anything diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst index b38bf2054ce3..58bc047e7b95 100644 --- a/Documentation/process/submitting-drivers.rst +++ b/Documentation/process/submitting-drivers.rst @@ -16,7 +16,8 @@ you should probably talk to XFree86 (http://www.xfree86.org/) and/or X.Org Oh, and we don't really recommend submitting changes to XFree86 :) -Also read the Documentation/process/submitting-patches.rst document. +Also read the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` +document. Allocating Device Numbers @@ -27,7 +28,8 @@ by the Linux assigned name and number authority (currently this is Torben Mathiasen). The site is http://www.lanana.org/. This also deals with allocating numbers for devices that are not going to be submitted to the mainstream kernel. -See Documentation/admin-guide/devices.rst for more information on this. +See :ref:`Documentation/admin-guide/devices.rst <admin_devices>` +for more information on this. If you don't use assigned numbers then when your device is submitted it will be given an assigned number even if that is different from values you may @@ -117,7 +119,7 @@ PM support: anything. For the driver testing instructions see Documentation/power/drivers-testing.txt and for a relatively complete overview of the power management issues related to - drivers see Documentation/driver-api/pm/devices.rst. + drivers see :ref:`Documentation/driver-api/pm/devices.rst <driverapi_pm_devices>`. Control: In general if there is active maintenance of a driver by |