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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
==============================
Hyra Contribution Guidelines
==============================
!! C PROGRAMMING STYLE !!
The .vimrc file that follows this style can be found in
share/misc/vimrc
Indent width is 4-spaces (NO TABS)
The typename must go above the function name like so:
static inline bool
is_power_of_two(uint8_t n)
{
if (g_foo) {
...
}
return ((n & 0x01) == 0);
}
--
When defining local variables in functions, they
must be declared at the top:
static void
foo(void)
{
uint8_t byte;
uint16_t pair;
uint32_t quad;
uint64_t oct;
...
}
--
When checking if an integer is 0 or not, *be explicit* unless it is a bool!
Do not do this:
#define BLAH 1
if (!BLAH) {
...
}
Do this instead:
if (BLAH == 0) {
...
}
-- or if it is a bool:
#define BLAH true
if (!blah) {
...
}
--
When writing switch statements, no indentation is needed
before the "case" statement, do this:
switch (v) {
case 0:
...
break;
case 1:
...
break;
case 2:
...
break;
}
Not this:
switch (v) {
case 0:
...
break;
case 1:
...
break;
case 2:
...
break;
}
--
Now, only use predefined integer types in sys/cdefs.h like so:
uint8_t a;
uint16_t b;
uint32_t c;
--
All includes must be done with '< >':
#include <sys/cdefs.h>
--
When including architecture specific things, it would be stupid
to include for another architecture. Only include from machine/ which
points to the architecture specific files for the current architecture.
For example:
/* AMD64-specific, in sys/include/arch/amd64/lapic.h */
#include <machine/lapic.h>
--
Avoid initializing variables to e.g. 0 unless it seems wise to do so.
Try to avoid this:
uint8_t foo = 0;
...
It is best to do this instead:
uint8_t foo;
...
foo = some_calculation();
--
One of the only times it is best to do that is when you have
a pointer, like, for example:
uint8_t *ptr = NULL;
...
--
The preferred pointer style is:
void *p = ...;
-- Not:
void* p = ...;
-- or if you have for example, some sort of counter value
that must have a start:
uint8_t countdown = COUNTDOWN_START;
--
!! COMMIT STYLE !!
Keep commits small if possible. Follow commit good practices.
- Commit examples -
1) Some manpage update:
docs: man: Describe foo in foobar(9)
2) Adding a tool in tools/
build: tools: Create foo
This commit adds a new script in tools/
that does x and y ...
- Kernel commits -
An example of a commit title for a non architecture-specific commit:
kernel: foo: Fix bar in foobar
An example of an architecture specific commit e.g. for AMD64:
kernel/amd64: foo: Add foo in bar
- Ready to commit -
(BE SURE TO TEST IT!! IDEALLY ON REAL HW TOO IF POSSIBLE!)
* Commit with `git commit -sv`
* Create patch with `git format-patch -1 HEAD`
* Email patch to ian@osmora.org and for better response times,
optionally CC to quinn@osmora.org
Done!
------------------------------------------------
NOTE TO MAINTAINERS
For those who maintain the Hyra repo, when testing a patch, apply it like so:
`git am -s patchfile.patch`. If all good, create a new patch and email it to
ian@osmora.org
|
