From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933210AbcINLOh (ORCPT ); Wed, 14 Sep 2016 07:14:37 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:40266 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761611AbcINLM6 (ORCPT ); Wed, 14 Sep 2016 07:12:58 -0400 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab , Markus Heiser , Jonathan Corbet , Jani Nikula , LKML Subject: [PATCH v3 10/21] Documentation/CodingStyle: use the .. note:: markup where needed Date: Wed, 14 Sep 2016 08:06:39 -0300 Message-Id: <1b9bfb9df65e5cc2fc43cb014b118d2bc652bb8b.1473849886.git.mchehab@s-opensource.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- Documentation/CodingStyle | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index e669ecdcd8fe..ef5b84417224 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -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