summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJonathan Corbet <corbet@lwn.net>2016-09-20 18:46:36 -0600
committerJonathan Corbet <corbet@lwn.net>2016-09-20 18:46:36 -0600
commit1b49ecf2f3be358882bb97652ba50ae808c0ba8f (patch)
tree76c5b95e614cfa79aac5b60e2d43259a28ed9351
parent7a71a8095bcfb33d0798365465699c6db545b914 (diff)
docs: Clean up bare :: lines
Mauro's patch set introduced some bare :: lines; these can be represented by a double colon at the end of the preceding text line. The result looks a little less weird and is less verbose. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-rw-r--r--Documentation/Changes12
-rw-r--r--Documentation/HOWTO12
-rw-r--r--Documentation/applying-patches.txt44
3 files changed, 17 insertions, 51 deletions
diff --git a/Documentation/Changes b/Documentation/Changes
index 754cd50c1bc6..22797a15dc24 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -212,9 +212,7 @@ Intel IA32 microcode
A driver has been added to allow updating of Intel IA32 microcode,
accessible as a normal (misc) character device. If you are not using
-udev you may need to:
-
-::
+udev you may need to::
mkdir /dev/cpu
mknod /dev/cpu/microcode c 10 184
@@ -260,9 +258,7 @@ enable it to operate over diverse media layers. If you use PPP,
upgrade pppd to at least 2.4.0.
If you are not using udev, you must have the device file /dev/ppp
-which can be made by:
-
-::
+which can be made by::
mknod /dev/ppp c 108 0
@@ -294,9 +290,7 @@ appropriate export information to the kernel. This removes the
dependency on ``rmtab`` and means that the kernel only needs to know about
currently active clients.
-To enable this new functionality, you need to:
-
-::
+To enable this new functionality, you need to::
mount -t nfsd nfsd /proc/fs/nfsd
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index adde88a6d9c4..5f042349f987 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -167,9 +167,7 @@ ReStructuredText markups (ReST), like this one. This includes a
full description of the in-kernel API, and rules on how to handle
locking properly.
-All such documents can be generated as PDF or HTML by running:
-
-::
+All such documents can be generated as PDF or HTML by running::
make pdfdocs
make htmldocs
@@ -177,9 +175,7 @@ All such documents can be generated as PDF or HTML by running:
respectively from the main kernel source directory.
The documents that uses ReST markup will be generated at Documentation/output.
-They can also be generated on LaTeX and ePub formats with:
-
-::
+They can also be generated on LaTeX and ePub formats with::
make latexdocs
make epubdocs
@@ -187,9 +183,7 @@ They can also be generated on LaTeX and ePub formats with:
Currently, there are some documents written on DocBook that are in
the process of conversion to ReST. Such documents will be created in the
Documentation/DocBook/ directory and can be generated also as
-Postscript or man pages by running:
-
-::
+Postscript or man pages by running::
make psdocs
make mandocs
diff --git a/Documentation/applying-patches.txt b/Documentation/applying-patches.txt
index bc113bff86b7..02ce4924468e 100644
--- a/Documentation/applying-patches.txt
+++ b/Documentation/applying-patches.txt
@@ -54,15 +54,11 @@ in the patch file when applying it (the ``-p1`` argument to ``patch`` does
this).
To revert a previously applied patch, use the -R argument to patch.
-So, if you applied a patch like this:
-
-::
+So, if you applied a patch like this::
patch -p1 < ../patch-x.y.z
-You can revert (undo) it like this:
-
-::
+You can revert (undo) it like this::
patch -R -p1 < ../patch-x.y.z
@@ -74,9 +70,7 @@ This (as usual with Linux and other UNIX like operating systems) can be
done in several different ways.
In all the examples below I feed the file (in uncompressed form) to patch
-via stdin using the following syntax:
-
-::
+via stdin using the following syntax::
patch -p1 < path/to/patch-x.y.z
@@ -85,26 +79,20 @@ know of more than one way to use patch, then you can stop reading this
section here.
Patch can also get the name of the file to use via the -i argument, like
-this:
-
-::
+this::
patch -p1 -i path/to/patch-x.y.z
If your patch file is compressed with gzip or xz and you don't want to
uncompress it before applying it, then you can feed it to patch like this
-instead:
-
-::
+instead::
xzcat path/to/patch-x.y.z.xz | patch -p1
bzcat path/to/patch-x.y.z.gz | patch -p1
If you wish to uncompress the patch file by hand first before applying it
(what I assume you've done in the examples below), then you simply run
-gunzip or xz on the file -- like this:
-
-::
+gunzip or xz on the file -- like this::
gunzip patch-x.y.z.gz
xz -d patch-x.y.z.xz
@@ -232,9 +220,7 @@ step. The -z flag to interdiff will even let you feed it patches in gzip or
bzip2 compressed form directly without the use of zcat or bzcat or manual
decompression.
-Here's how you'd go from 4.7.2 to 4.7.3 in a single step:
-
-::
+Here's how you'd go from 4.7.2 to 4.7.3 in a single step::
interdiff -z ../patch-4.7.2.gz ../patch-4.7.3.gz | patch -p1
@@ -289,9 +275,7 @@ that such patches do **NOT** apply on top of 4.x.y kernels but on top of the
base 4.x kernel -- if you need to move from 4.x.y to 4.x+1 you need to
first revert the 4.x.y patch).
-Here are some examples:
-
-::
+Here are some examples::
# moving from 4.6 to 4.7
@@ -339,9 +323,7 @@ So, in order to apply the 4.7.3 patch to your existing 4.7.2 kernel
source you have to first back out the 4.7.2 patch (so you are left with a
base 4.7 kernel source) and then apply the new 4.7.3 patch.
-Here's a small example:
-
-::
+Here's a small example::
$ cd ~/linux-4.7.2 # change to the kernel source dir
$ patch -p1 -R < ../patch-4.7.2 # revert the 4.7.2 patch
@@ -374,9 +356,7 @@ turn into.
So, 4.8-rc5 means that this is the fifth release candidate for the 4.8
kernel and the patch should be applied on top of the 4.7 kernel source.
-Here are 3 examples of how to apply these patches:
-
-::
+Here are 3 examples of how to apply these patches::
# first an example of moving from 4.7 to 4.8-rc3
@@ -418,9 +398,7 @@ a base 4.x-rc kernel -- you can see which from their name.
A patch named 4.7-git1 applies to the 4.7 kernel source and a patch
named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel.
-Here are some examples of how to apply these patches:
-
-::
+Here are some examples of how to apply these patches::
# moving from 4.7 to 4.7-git1