linux-kernel - [PATCH v2 08/20] CodingStyle.rst: use the .. note:: markup where needed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Sep 2016 23:17:59 -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>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Joe Perches <joe@...ches.com>,
        Manuel Pégourié-Gonnard <mpg@...evir.fr>,
        Thomas Gardner <tmg@...tmail.com>,
        Jean Delvare <jdelvare@...e.de>
Subject: [PATCH v2 08/20] CodingStyle.rst: use the .. note:: markup where needed

There are two places there where there are notes that should
be bold. So, use the right markup for that.

Signed-off-by: Mauro Carvalho Chehab <mchehab@...pensource.com>
---
 Documentation/development-process/CodingStyle.rst | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/development-process/CodingStyle.rst b/Documentation/development-process/CodingStyle.rst
index 1829b1ad7ef8..d9debafbd2eb 100644
--- a/Documentation/development-process/CodingStyle.rst
+++ b/Documentation/development-process/CodingStyle.rst
@@ -344,9 +344,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``.
@@ -354,8 +356,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