[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7da1040d38b8f74969b0d6dc6e9a6ea3de0e4ac9.1474280152.git.mchehab@s-opensource.com>
Date: Mon, 19 Sep 2016 08:07:47 -0300
From: Mauro Carvalho Chehab <mchehab@...pensource.com>
To: Linux Doc Mailing List <linux-doc@...r.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@...pensource.com>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
Markus Heiser <markus.heiser@...marit.de>,
Jonathan Corbet <corbet@....net>,
Jani Nikula <jani.nikula@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>
Subject: [PATCH v4 13/29] Documentation/CodingStyle: use the .. note:: markup where needed
There are two places there where there are notes that should
be highlighted. So, use the ReST note markup for such texts.
Signed-off-by: Mauro Carvalho Chehab <mchehab@...pensource.com>
---
Documentation/CodingStyle | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 0024c36b8046..7e30da38bb3a 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -333,9 +333,11 @@ useful only for:
Example: ``pte_t`` etc. opaque objects that you can only access using
the proper accessor functions.
- NOTE! Opaqueness and ``accessor functions`` are not good in themselves.
- The reason we have them for things like pte_t etc. is that there
- really is absolutely **zero** portably accessible information there.
+ .. note::
+
+ Opaqueness and ``accessor functions`` are not good in themselves.
+ The reason we have them for things like pte_t etc. is that there
+ really is absolutely **zero** portably accessible information there.
(b) Clear integer types, where the abstraction **helps** avoid confusion
whether it is ``int`` or ``long``.
@@ -343,8 +345,10 @@ useful only for:
u8/u16/u32 are perfectly fine typedefs, although they fit into
category (d) better than here.
- NOTE! Again - there needs to be a **reason** for this. If something is
- ``unsigned long``, then there's no reason to do
+ .. note::
+
+ Again - there needs to be a **reason** for this. If something is
+ ``unsigned long``, then there's no reason to do
typedef unsigned long myflags_t;
--
2.7.4
Powered by blists - more mailing lists