doc:process: add links where missing

Some documents are refering to others without links. With this
patch I add those missing links.

This patch affects only documents under process/ and labels where
necessary.

Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Federico Vaga 2018-11-21 01:35:19 +01:00 committed by Jonathan Corbet
parent 2f7e6f6bf0
commit f77af637f2
12 changed files with 42 additions and 26 deletions

View File

@ -1,3 +1,4 @@
.. _admin_devices:
Linux allocated devices (4.x+ version)
======================================

View File

@ -4,6 +4,8 @@
.. highlight:: none
.. _devtools_coccinelle:
Coccinelle
==========

View File

@ -1,3 +1,5 @@
.. _sphinxdoc:
Introduction
============

View File

@ -6,6 +6,8 @@
.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source <wakeup_source>`
.. |struct device| replace:: :c:type:`struct device <device>`
.. _driverapi_pm_devices:
==============================
Device Power Management Basics
==============================

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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