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>hifive-unleashed-5.1
Federico Vaga
Jonathan Corbet
parent
2f7e6f6bf0
commit
f77af637f2
|
|
@ -1,3 +1,4 @@
|
|||
.. _admin_devices:
|
||||
|
||||
Linux allocated devices (4.x+ version)
|
||||
======================================
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
.. highlight:: none
|
||||
|
||||
.. _devtools_coccinelle:
|
||||
|
||||
Coccinelle
|
||||
==========
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _sphinxdoc:
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
==============================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue