OpenOCD
HACKING
Go to the documentation of this file.
1 // This file is part of the Doxygen Developer Manual
2 /** @page patchguide Patch Guidelines
3 
4 \attention You can't send patches to the mailing list anymore at all. Nowadays
5 you are expected to send patches to the OpenOCD Gerrit GIT server for a
6 review.
7 
8 \attention If you already have a Gerrit account and want to try a
9 different sign in method, please first sign in as usually, press your
10 name in the upper-right corner, go to @a Settings, select @a
11 Identities pane, press <em>Link Another Identity</em> button. In case
12 you already have duplicated accounts, ask administrators for manual
13 merging.
14 
15 \attention If you're behind a corporate wall with http only access to the
16 world, you can still use these instructions!
17 
18 @section gerrit Submitting patches to the OpenOCD Gerrit server
19 
20 OpenOCD is to some extent a "self service" open source project, so to
21 contribute, you must follow the standard procedures to have the best
22 possible chance to get your changes accepted.
23 
24 The procedure to create a patch is essentially:
25 
26 - make the changes
27 - create a commit
28 - send the changes to the Gerrit server for review
29 - correct the patch and re-send it according to review feedback
30 
31 Your patch (or commit) should be a "good patch": focus it on a single
32 issue, and make it easily reviewable. Don't make
33 it so large that it's hard to review; split large
34 patches into smaller ones (this will also help
35 to track down bugs later). All patches should
36 be "clean", which includes preserving the existing
37 coding style and updating documentation as needed. When adding a new
38 command, the corresponding documentation should be added to
39 @c doc/openocd.texi in the same commit. OpenOCD runs on both Little
40 Endian and Big Endian hosts so the code can't count on specific byte
41 ordering (in other words, must be endian-clean).
42 
43 There are several additional methods of improving the quality of your
44 patch:
45 
46 - Runtime testing with Valgrind Memcheck
47 
48  This helps to spot memory leaks, undefined behaviour due to
49  uninitialized data or wrong indexing, memory corruption, etc.
50 
51 - Clang Static Analyzer
52 
53  Using this tool uncovers many different kinds of bugs in C code,
54  with problematic execution paths fully explained. It is a part of
55  standard Clang installation.
56 
57  To generate a report, run this in the OpenOCD source directory:
58  @code
59  mkdir build-scanbuild; cd build-scanbuild
60  scan-build ../configure
61  scan-build make CFLAGS="-std=gnu99 -I. -I../../jimtcl"
62  @endcode
63 
64 - Runtime testing with sanitizers
65 
66  Both GCC and LLVM/Clang include advanced instrumentation options to
67  detect undefined behaviour and many kinds of memory
68  errors. Available with @c -fsanitize=* command arguments.
69 
70  Example usage:
71  @code
72  mkdir build-sanitizers; cd build-sanitizers
73  ../configure CC=clang CFLAGS="-fno-omit-frame-pointer \
74  -fsanitize=address -fsanitize=undefined -ggdb3"
75  make
76  export ASAN_OPTIONS=detect_stack_use_after_return=1
77  src/openocd -s ../tcl -f /path/to/openocd.cfg
78  @endcode
79 
80 - Sparse Static Analyzer
81 
82  Using this tool allows identifying some bug in C code.
83  In the future, OpenOCD would use the sparse attribute 'bitwise' to
84  detect incorrect endianness assignments.
85 
86  Example usage:
87  @code
88  mkdir build-sparse; cd build-sparse
89  ../configure CC=cgcc CFLAGS="-Wsparse-all -Wno-declaration-after-statement \
90  -Wno-unknown-attribute -Wno-transparent-union -Wno-tautological-compare \
91  -Wno-vla -Wno-flexible-array-array -D__FLT_EVAL_METHOD__=0"
92  make
93  @endcode
94 
95 Please consider performing these additional checks where appropriate
96 (especially Clang Static Analyzer for big portions of new code) and
97 mention the results (e.g. "Valgrind-clean, no new Clang analyzer
98 warnings") in the commit message.
99 
100 Say in the commit message if it's a bugfix (describe the bug) or a new
101 feature. Don't expect patches to merge immediately
102 for the next release. Be ready to rework patches
103 in response to feedback.
104 
105 Add yourself to the GPL copyright for non-trivial changes.
106 
107 @section stepbystep Step by step procedure
108 
109 -# Create a Gerrit account at: https://review.openocd.org
110  - On subsequent sign ins, use the full URL prefaced with 'http://'
111  For example: http://user_identifier.open_id_provider.com
112  -# Add a username to your profile.
113  After creating the Gerrit account and signing in, you will need to
114  add a username to your profile. To do this, go to 'Settings', and
115  add a username of your choice.
116  Your username will be required in step 3 and substituted wherever
117  the string 'USERNAME' is found.
118  -# Create an SSH public key following the directions on github:
119  https://help.github.com/articles/generating-ssh-keys . You can skip step 3
120  (adding key to Github account) and 4 (testing) - these are useful only if
121  you actually use Github or want to test whether the new key works fine.
122  -# Add this new SSH key to your Gerrit account:
123  go to 'Settings' > 'SSH Public Keys', paste the contents of
124  ~/.ssh/id_rsa.pub into the text field (if it's not visible click on
125  'Add Key ...' button) and confirm by clicking 'Add' button.
126 -# Clone the git repository, rather than just download the source:
127  @code
128  git clone git://git.code.sf.net/p/openocd/code openocd
129  @endcode
130  or if you have problems with the "git:" protocol, use
131  the slower http protocol:
132  @code
133  git clone http://git.code.sf.net/p/openocd/code openocd
134  @endcode
135 -# Set up Gerrit with your local repository. All this does it
136 to instruct git locally how to send off the changes.
137  -# Add a new remote to git using Gerrit username:
138 @code
139 git remote add review ssh://USERNAME@review.openocd.org:29418/openocd.git
140 git config remote.review.push HEAD:refs/for/master
141 @endcode
142  Or with http only:
143 @code
144 git remote add review https://USERNAME@review.openocd.org/p/openocd.git
145 git config remote.review.push HEAD:refs/for/master
146 @endcode
147  The http password is configured from your gerrit settings - https://review.openocd.org/#/settings/http-password.
148  \note If you want to simplify http access you can also add your http password to the url as follows:
149 @code
150 git remote add review https://USERNAME:PASSWORD@review.openocd.org/p/openocd.git
151 @endcode
152  \note All contributions should be pushed to @c refs/for/master on the
153 Gerrit server, even if you plan to use several local branches for different
154 topics. It is possible because @c for/master is not a traditional Git
155 branch.
156  -# You will need to install this hook, we will look into a better solution:
157 @code
158 wget https://review.openocd.org/tools/hooks/commit-msg
159 mv commit-msg .git/hooks
160 chmod +x .git/hooks/commit-msg
161 @endcode
162  \note A script exists to simplify the two items above. Execute:
163 @code
164 tools/initial.sh <username>
165 @endcode
166 With @<username@> being your Gerrit username.
167 -# Set up git with your name and email:
168 @code
169 git config --global user.name "John Smith"
170 git config --global user.email "john@smith.org"
171 @endcode
172 -# Work on your patches. Split the work into
173  multiple small patches that can be reviewed and
174  applied separately and safely to the OpenOCD
175  repository.
176 @code
177 while(!done) {
178  work - edit files using your favorite editor.
179  run "git commit -s -a" to commit all changes.
180  run tools/checkpatch.sh to verify your patch style is ok.
181 }
182 @endcode
183  \note use "git add ." before commit to add new files.
184 
185  \note check @ref checkpatch for hint about checkpatch script
186 
187  Commit message template, notice the short first line.
188  The field '<c>specify touched area</c>'
189  should identify the main part or subsystem the patch touches.
190 @code{.unparsed}
191 specify touched area: short comment
192 <blank line>
193 Longer comments over several lines, explaining (where applicable) the
194 reason for the patch and the general idea the solution is based on,
195 any major design decisions, etc. Limit each comment line's length to 75
196 characters; since 75 it's too short for a URL, you can put the URL in a
197 separate line preceded by 'Link: '.
198 <blank line>
199 Signed-off-by: ...
200 @endcode
201  Examples:
202 @code{.unparsed}
203 flash/nor/atsame5: add SAME59 support
204 
205 Add new device ID
206 @endcode
207 @code{.unparsed}
208 flash/nor: flash driver for XYZ123
209 
210 Add new flash driver for internal flash of ...
211 @endcode
212 @code{.unparsed}
213 target/cortex_m: fix segmentation fault in cmd 'soft_reset_halt'
214 
215 soft_reset_halt command failed reproducibly under following conditions: ...
216 Test for NULL pointer and return error ...
217 
218 Reported-by: John Reporter <rep9876@gmail.com>
219 Fixes: 123456789abc ("target: the commit where the problem started")
220 BugLink: https://sourceforge.net/p/openocd/tickets/999/
221 @endcode
222 @code{.unparsed}
223 doc: fix typos
224 @endcode
225  See "git log" for more examples.
226 
227 -# Next you need to make sure that your patches
228  are on top of the latest stuff on the server and
229  that there are no conflicts:
230 @code
231 git pull --rebase origin master
232 @endcode
233 -# Send the patches to the Gerrit server for review:
234 @code
235 git push review
236 @endcode
237 -# Forgot something, want to add more? Just make the changes and do:
238 @code
239 git commit --amend
240 git push review
241 @endcode
242 
243 Further reading: http://www.coreboot.org/Git
244 
245 @section checkpatch About checkpatch script
246 
247 OpenOCD source code includes the script checkpatch to let developers to
248 verify their patches before submitting them for review (see @ref gerrit).
249 
250 Every patch for OpenOCD project that is submitted for review on Gerrit
251 is tested by Jenkins. Jenkins will run the checkpatch script to analyze
252 each patch.
253 If the script highlights either errors or warnings, Gerrit will add the
254 score "-1" to the patch and maintainers will probably ignore the patch,
255 waiting for the developer to send a fixed version.
256 
257 The script checkpatch verifies the SPDX tag for new files against a very
258 short list of license tags.
259 If the license of your contribution is not listed there, but compatible
260 with OpenOCD license, please alert the maintainers or add the missing
261 license in the first patch of your patch series.
262 
263 The script checkpatch has been originally developed for the Linux kernel
264 source code, thus includes specific tests and checks related to Linux
265 coding style and to Linux code structure. While the script has been
266 adapted for OpenOCD specificities, it still includes some Linux related
267 test. It is then possible that it triggers sometimes some <em>false
268 positive</em>!
269 
270 If you think that the error identified by checkpatch is a false
271 positive, please report it to the openocd-devel mailing list or prepare
272 a patch for fixing checkpatch and send it to Gerrit for review.
273 
274 \attention The procedure below is allowed only for <em>exceptional
275 cases</em>. Do not use it to submit normal patches.
276 
277 There are <em>exceptional cases</em> in which you need to skip some of
278 the tests from checkpatch in order to pass the approval from Gerrit.
279 
280 For example, a patch that modify one line inside a big comment block
281 will not show the beginning or the end of the comment block. This can
282 prevent checkpatch to detect the comment block. Checkpatch can wrongly
283 consider the modified comment line as a code line, triggering a set of
284 false errors.
285 
286 Only for <em>exceptional cases</em>, it is allowed to submit patches
287 to Gerrit with the special field 'Checkpatch-ignore:' in the commit
288 message. This field will cause checkpatch to ignore the error types
289 listed in the field, only for the patch itself.
290 The error type is printed by checkpatch on failure.
291 For example the names of Windows APIs mix lower and upper case chars,
292 in violation of OpenOCD coding style, triggering a 'CAMELCASE' error:
293 @code
294 CHECK:CAMELCASE: Avoid CamelCase: <WSAGetLastError>
295 #96105: FILE: src/helper/log.c:505:
296 + error_code = WSAGetLastError();
297 @endcode
298 Adding in the commit message of the patch the line:
299 @code
300 Checkpatch-ignore: CAMELCASE
301 @endcode
302 will force checkpatch to ignore the CAMELCASE error.
303 
304 @section timeline When can I expect my contribution to be committed?
305 
306 The code review is intended to take as long as a week or two to allow
307 maintainers and contributors who work on OpenOCD only in their spare
308 time opportunity to perform a review and raise objections.
309 
310 With Gerrit much of the urgency of getting things committed has been
311 removed as the work in progress is safely stored in Gerrit and
312 available if someone needs to build on your work before it is
313 submitted to the official repository.
314 
315 Another factor that contributes to the desire for longer cool-off
316 times (the time a patch lies around without any further changes or
317 comments), it means that the chances of quality regression on the
318 master branch will be much reduced.
319 
320 If a contributor pushes a patch, it is considered good form if another
321 contributor actually approves and submits that patch.
322 
323 It should be noted that a negative review in Gerrit ("-1" or "-2") may (but does
324 not have to) be disregarded if all conditions listed below are met:
325 
326 - the concerns raised in the review have been addressed (or explained),
327 - reviewer does not re-examine the change in a month,
328 - reviewer does not answer e-mails for another month.
329 
330 @section browsing Browsing Patches
331 All OpenOCD patches can be reviewed <a href="https://review.openocd.org/">here</a>.
332 
333 @section reviewing Reviewing Patches
334 From the main <a href="https://review.openocd.org/#/q/status:open,n,z">Review
335 page</a> select the patch you want to review and click on that patch. On the
336 appearing page select the download method (top right). Apply the
337 patch. After building and testing you can leave a note with the "Reply"
338 button and mark the patch with -1, 0 and +1.
339 */
340 /** @file
341 This file contains the @ref patchguide page.
342 */