]>
Commit | Line | Data |
---|---|---|
a2353f60 UH |
1 | ------------------------------------------------------------------------------- |
2 | HACKING | |
3 | ------------------------------------------------------------------------------- | |
4 | ||
5 | Coding style | |
6 | ------------ | |
7 | ||
8 | This project is programmed using the Linux kernel coding style, see | |
9 | http://lxr.linux.no/linux/Documentation/CodingStyle for details. | |
10 | ||
11 | Please use the same style for any code contributions, thanks! | |
12 | ||
13 | ||
14 | Contributions | |
15 | ------------- | |
16 | ||
17 | - Patches should be sent to the development mailinglist at | |
18 | sigrok-devel@lists.sourceforge.net (please subscribe to the list first). | |
19 | ||
20 | https://lists.sourceforge.net/lists/listinfo/sigrok-devel | |
21 | ||
22 | - Alternatively, you can also clone the git repository and let us know | |
23 | from where to pull/review your changes. You can use gitorious.org, | |
24 | github.com, or any other public git hosting site. | |
25 | ||
26 | ||
2bba3dd3 UH |
27 | Adding a new hardware driver |
28 | ---------------------------- | |
29 | ||
30 | The simple, scripted way (recommended): | |
31 | --------------------------------------- | |
32 | ||
33 | Use the 'new-driver' script from the sigrok-util repo: | |
34 | ||
35 | $ git clone git://sigrok.org/sigrok-util | |
36 | $ cd sigrok-util/source | |
37 | $ ./new-driver "Tondaj SL-814" | |
38 | ||
39 | The example above generates a patch file against the current libsigrok | |
40 | development git tree which adds a simple "stub" driver for your device | |
41 | (the Tondaj SL-814 sound level meter in this case). | |
42 | ||
43 | You can apply it like this: | |
44 | ||
45 | $ cd libsigrok | |
46 | $ git am 0001-tondaj-sl-814-Initial-driver-skeleton.patch | |
47 | ||
48 | You can now edit the files in the hardware/tondaj-sl-814 directory as needed. | |
49 | ||
50 | ||
51 | The manual way: | |
52 | --------------- | |
53 | ||
54 | This is a rough overview of what you need to do in order to add a new driver | |
55 | (using the Tondaj SL-814 device as example). It's basically what the | |
56 | 'new-driver' script (see above) does for you: | |
57 | ||
58 | - configure.ac: | |
59 | - Add an --enable-tondaj-sl-814 option. | |
60 | - Add "hardware/tondaj-sl-814/Makefile" to the AC_CONFIG_FILES list. | |
61 | - Add and entry for the device in the "Enabled hardware drivers" list | |
62 | at the bottom of the file. | |
63 | - hardware/Makefile.am: Add "tondaj-sl-814" to the SUBDIRS variable. | |
64 | - hwdriver.c: Add a tondaj_sl_814_driver_info entry in two places. | |
65 | - hardware/tondaj-sl-814/ directory: Add the following files: | |
66 | Makefile.am, api.c, protocol.c, protocol.h | |
67 | ||
68 | See existing drivers or the 'new-driver' output for the details. | |
69 | ||
70 | ||
a2353f60 UH |
71 | Random notes |
72 | ------------ | |
73 | ||
74 | - Consistently use g_try_malloc() / g_try_malloc0(). Do not use standard | |
75 | malloc()/calloc() if it can be avoided (sometimes other libs such | |
76 | as libftdi can return malloc()'d memory, for example). | |
77 | ||
78 | - Always properly match allocations with the proper *free() functions. If | |
79 | glib's g_try_malloc()/g_try_malloc0() was used, use g_free() to free the | |
80 | memory. Otherwise use standard free(). Never use the wrong function! | |
81 | ||
82 | - Never use g_malloc() or g_malloc0(). These functions do not return NULL | |
83 | if not enough memory is available but rather lead to an exit() or segfault | |
8ed26250 | 84 | instead. This behaviour is not acceptable for libraries. |
a2353f60 UH |
85 | Use g_try_malloc()/g_try_malloc0() instead and check the return value. |
86 | ||
8ed26250 | 87 | - You should never print any messages (neither to stdout nor stderr nor |
a2353f60 UH |
88 | elsewhere) "manually" via e.g. printf() or g_log() or similar functions. |
89 | Only sr_err()/sr_warn()/sr_info()/sr_dbg()/sr_spew() should be used. | |
90 | ||
91 | - Use glib's gboolean / TRUE / FALSE for boolean types consistently. | |
92 | Do not use <stdbool.h> and its true / false, and do not invent private | |
93 | definitions for this either. | |
94 | ||
95 | - Consistently use the same naming convention for #include guards in headers: | |
96 | <PROJECTNAME>_<PATH_TO_FILE>_<FILE> | |
97 | This ensures that all #include guards are always unique and consistent. | |
98 | Examples: LIBSIGROK_LIBSIGROK_H, LIBSIGROK_HARDWARE_ASIX_SIGMA_ASIX_SIGMA_H | |
99 | ||
100 | - Consistently use the same naming convention for API functions: | |
101 | <libprefix>_<groupname>_<action>(). | |
102 | ||
103 | Examples: | |
104 | sr_log_loglevel_set(), sr_log_loglevel_get(), sr_log_handler_set(), | |
105 | sr_log_handler_set_default(), and so on. | |
106 | Or: | |
107 | sr_session_new(), sr_session_destroy(), sr_session_load(), and so on. | |
108 | ||
109 | Getter/setter function names should usually end with "_get" or "_set". | |
110 | Functions creating new "objects" should end with "_new". | |
111 | Functions destroying "objects" should end with "_destroy". | |
112 | Functions adding or removing items (e.g. from lists) should end with | |
113 | either "_add" or "_remove". | |
114 | Functions operating on all items from a list (not on only one of them), | |
115 | should end with "_all", e.g. "_remove_all", "_get_all", and so on. | |
116 | Use "_remove_all" in favor of "_clear" for consistency. | |
117 | ||
f18297a5 UH |
118 | - All enums should generally use an explicit start number of 10000. |
119 | If there are multiple "categories" in the enum entries, each category | |
120 | should be 10000 entries apart from the next one. The start of categories | |
121 | are thus 10000, 20000, 30000, and so on. | |
122 | ||
123 | Adding items to an enum MUST always append to a "category", never add | |
124 | items in the middle of a category. The order of items MUST NOT be changed. | |
125 | Any of the above would break the ABI. | |
126 | ||
127 | The enum item 0 is special and is used as terminator in some lists, thus | |
128 | enums should not use this for "valid" entries (and start at 10000 instead). | |
129 | ||
b4bd7088 UH |
130 | |
131 | Doxygen | |
132 | ------- | |
133 | ||
a2353f60 UH |
134 | - In Doxygen comments, put an empty line between the block of @param lines |
135 | and the final @return line. The @param lines themselves (if there is more | |
136 | than one) are not separated by empty lines. | |
137 | ||
b4bd7088 UH |
138 | - Mark private functions (SR_PRIV) with /** @private */, so that Doxygen |
139 | doesn't include them in the output. Functions that are "static" anyway | |
140 | don't need to be marked like this. | |
141 | ||
142 | - Mark private variables/#defines with /** @cond PRIVATE */ and | |
143 | /** @endcond */, so that Doxygen doesn't include them in the output. | |
144 | Variables that are "static" don't need to be marked like this. | |
145 | ||
9fb5f2df UH |
146 | - Mark all public API functions (SR_API) with a @since tag which indicates |
147 | in which release the respective function was added. If the function has | |
148 | existed before, but its API changed later, document this as well. | |
149 | ||
150 | Non-public functions (static ones, and those marked SR_PRIV) don't need | |
151 | to have @since markers. | |
152 | ||
153 | The @since tag should be the last one, i.e. it should come after @param, | |
154 | @return, @see, and so on. | |
155 | ||
156 | Examples: | |
157 | ||
158 | @since 0.1.0 | |
159 | ||
160 | @since 0.1.1 (but the API changed in 0.2.0) | |
161 | ||
a2353f60 | 162 | |
79bb0e97 UH |
163 | Testsuite |
164 | --------- | |
165 | ||
166 | You can run the libsigrok testsuite using: | |
167 | ||
168 | $ make check | |
169 | ||
170 | ||
a2353f60 UH |
171 | Release engineering |
172 | ------------------- | |
173 | ||
174 | See | |
175 | ||
176 | http://sigrok.org/wiki/Developers/Release_process | |
177 | ||
178 | for a list of items that need to be done when releasing a new tarball. | |
179 |