mirror of https://gitee.com/openkylin/linux.git
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@s-opensource.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
5d628b4527
commit
3772ec4adf
|
@ -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;
|
||||
|
||||
|
|
Loading…
Reference in New Issue