+.. _codingstyle:
+
Linux kernel coding style
=========================
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``.
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;
renumber them if you ever add or remove exit paths, and they make correctness
difficult to verify anyway.
-It is advised to indent labels with a single space (not tab), so that
-``diff -p`` does not confuse labels with functions.
-
The rationale for using gotos is:
- unconditional statements are easier to understand and follow
goto out_buffer;
}
...
- out_free_buffer:
+ out_free_buffer:
kfree(buffer);
return result;
}
.. code-block:: c
- err:
+ err:
kfree(foo->bar);
kfree(foo);
return ret;