blob: d5b3bb2f4b402125bfe6fb21afe68b6bf34b63aa [file] [log] [blame]
Austin Schuh8d0a2852019-12-28 22:54:28 -08001This is the style guide for the LKSCTP Project.
2<http://www.sf.net/projects/lksctp/>
3
41.0 Introduction
5
6Use the Linux kernel coding style as the base,
7linux/Documentation/CodingStyle.
8
9This is intended as the IETF kernel reference code for RFC2960 and the
10SCTP API. As such, readability is paramount. We attempt to follow
11the names from RFC2960 as closely as practical given the constrains of
12C and the Linux kernel naming conventions.
13
14Here are the approximate naming rules we use. Those marked
15[obsolescent] will go away once we purge the last vestiges of them.
16
171) [obsolescent] If a name appears in RFC 2960 or the API draft we try
18 to use it as closely as permitted by C syntax without ADDING "_".
19 This usually means names of the form "xyzAbc". E.g. "Duplicate TSN"
20 from RFC2960 became "DuplicateTSN", but "a_rwnd" is unaltered.
21
22New names should use this revised rule 1:
23
24 If a name appears in RFC 2960 or the API draft we try to use it as
25 closely as permitted by C syntax without using upper case letters.
26 This usually means names of the form "xyz_abc". E.g. "Duplicate
27 TSN" from RFC2960 became "duplicate_tsn", but "a_rwnd" is
28 unaltered. Remember the acronyms still need to be upper case in
29 comments.
30
312) [obsolescent] If a name refers to a struct which appears on the wire we use
32the form "struct xyzAbc". This is historically because we inherited most
33of these from the user space implementation. E.g. "struct sctpHeader".
34
353) There is no rule 3.
36
374) All functions start with "sctp_". Uh, yeah, well, uh...
38
395) Constants have the form "XYZ_ABC" per K&R.
40
416) [obsolecent] If "XYZ" is an acronym it SHOULD be capitalized as in
42 "XYZ_abc" or "XYZabc" unless overridden by rule 2 or rule 4. E.g.
43 "struct SCTP_association".
44
45New names should use this revised rule 6:
46
47 Names with anronyms SHOULD map them to lower case, E.g.
48 "struct sctp_association".
49
507) All remaining names SHOULD use the form "xyz_abc". E.g. "int too_big".
51
528) Deviations from these rules are bugs and need to be fixed.
53
54
552.0 Architectural and Procedural Standards
56
57The core metaphors are the state machine (sctp_do_sm(), related
58functions) and the smart pipe (inqueue, outqueue, ULPqueue, packet).
59
60The state machine breaks down into a pure functional core,
61sctp_sm_statefuns.c, with no side effects, and an explicit set of side
62effects, sctp_sm_sideeffects.c.
63
64Every function, typedef, enum, and struct needs a descriptive comment.
65
663.0 /* Comments */
67
68Except as noted below, make all comments full sentences.
69
70Proper behaviour is to spell-cheque your comments. Those colourful
71American spellings will not be rejected.
72
73Start all sentences with a capital letter. Do not begin sentences
74with symbols which must be all lower case. Sentences end with a
75period, question mark, or exclamation point. Punctuation at the end
76of a sentence has two trailing spaces or a trailing newline.
77
78Comments should confine themselves to expressing the INTENT of the code.
79
80If comments do not agree with the code, then we have a BUG.
81
82Passive voice should be avoided.
83
84Every function, typedef, enum, and struct needs a descriptive
85comment.
86
87/* All comments are C comments, */
88// not C++ comments.
89
90/* Multiline comments should
91 * look like this.
92 */
93
94Every #endif should include a comment describing the matching #if.
95E.g.
96
97#if 0
98#endif /* 0 */
99
100A struct sk_buff_head needs a comment describing the REAL type of its
101elements.
102
103To disable a section of code use
104#if 0
105#endif /* 0 */
106rather than /* */. The if/endif pair safely interoperates with
107existing comments.
108
1094.0 Appearance & Pretty printing
110
111Put a space after every keyword.
112
113Here is an example function:
114
115retval_t my_fun(int foo, struct SCTP_struct *bar)
116{
117 statement;
118}
119
120Every switch statement should have a default clause. If the default
121can never happen, default should crash or otherwise report failure.
122
123A loop with no body looks like this:
124
125 while (test()) {
126 /* Do nothing. */
127 }
128
129If a compound condition or arithemetic expression extends beyond the
13079 character limit, put the operators at the end of the line. E.g.
131
132 if ((NULL == map->tsn_map) ||
133 (NULL == map->overflow_map) ||
134 (map->len == 0)) {
135...
136
137
138The if/else style must follow that of K&R style, for example:
139
140 if (foo) {
141...
142 } else {
143...
144 }
145
146Unrequired whitespace should be removed from the end of lines and end of
147file. Hardtabs should be used where possible.
148
149
1505.0 Compiler and Behavior issues
151
152When comparing a constant to a variable, put the constant on the
153left. The compiler will tell you if you ommited a '='. E.g.
154
155 if (MY_CONSTANT == var) {
156 whatever();
157 }
158
159Please eliminate all compiler warnings. "Compilation errors are, in a
160way, unit test failures of their own. They tell us that the
161implementation does not match the specification." -- check.sf.net tutorial
162
163Please make forward declarations for all functions in the appropriate
164header files. This helps us detect interface changes.
165
166Whenever practical, allocate a large block of memory OUTSIDE a loop
167and then populate it inside the loop, rather than allocating many
168small blocks inside the loop.
169
170Do not use #ifdef TEST_FRAME unless absolutely necessary. In
171particular, if you simply call kernel functions which are not defined
172in the test frame, please add them to the test frame. The only case
173we know of which is difficult to handle is static inline functions.
174
175We require using this style of initialization:
176
177struct in_ifaddr eth2_ifa =
178 {.ifa_next = NULL, .ifa_dev = NULL, .ifa_local = 0, .ifa_address = 0};
179
180Keyword initializations are less susceptible to bugs due to changes in
181the underlying structures.
182
183
1846.0 Version changes
185
186The lksctp-tools packages uses the "M.m.p" versioning model for both
187the package itself & the provided shared libraries:
188
189- (M)-ajor revision change means both source & binary incompatibility
190 (user source code change might be required)
191
192- (m)-inor revision change means source compatibility, while ABI might
193 not be preserved (rebuild is required)
194
195- (p)-atchlevel change means that both API & ABI are preserved.