blob: 1372ed9ff706347a81cbab54dcfebbc981fa471a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
Contributing to the OpenDataplane (ODP) API
The ODP API follows the linux kernel coding style [1] and code submission
process [2], albeit patch submissions are to be submitted to the ODP
linaro-networking mailing list [3] (not LKML, etc.). ODP targets the C99 standard
and code should refrain from using gcc specific extensions in the interface and
in the linux-generic implementation or examples.
To certify you wrote the code, or otherwise have the right to pass it
on (presumably from a compatibly licensed project), we use the "Developer's
Certificate of Origin" (see [2]). Using this sign-off process, we are able to
keep track of compliance to our license (see LICENSE file).
There are tools we use to maintain CodingStyle and other good programming
practice consistency, including type-checking without overuse of casts.
(a) perform a one-time setup for the tools:
semantic parser 'sparse' [4]:
git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git
cd sparse
make
export PATH=$PATH:$PWD
(b) when building, use sparse to check for stricter type checking than the
compiler:
make CC=cgcc
(c) create patches with git:
git format-patch --subject-prefix="PATCH" --find-renames HEAD^
For prefixes see [3].
(d) Prior to submission, to style-check the patch 'file.patch', run:
./scripts/checkpatch.pl file.patch
Note: A common issue that causes patches to fail checkpatch is the
presense of trailing whitespace. Emacs users can use the command:
Meta-X delete-trailing-whitespace
to scrub the file prior to saving to avoid these issues. Vim users
can accomplish the same with the command:
:%s/\s\+$//
Please ensure submitted patches are checkpatch clean before submitting
them to avoid having them automatically returned for rework.
Documenting the code
Allow doxygen to use all its default behaviors to identify tagged
information but where a doxygen tag must be specified use @
The first line is by default the brief summary.
The next paragraph is by default the detailed summary
Normal comment sections should be before the code block and start with
/** on its own line and finish with */ on its own line. The exception
to this rule is a case where the comment is very small, for example
/** macro description */
#define SOME_MACRO 0
Commenting on the end of a line for macros and struct members is allowed using /**< <text> */ for example
#define SOME_MACRO 0 /**< <text> */
Files should start with a files description using @file
Functions should specify their parameters with @param[in] and @param[out]
Functions return values should all be specified using @return
There should be no doxygen warnings or errors generated.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
[3] refer to README file.
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/sparse.txt
|
