]>
Commit | Line | Data |
---|---|---|
1 | ------------------------------------------------------------------------------- | |
2 | HACKING | |
3 | ------------------------------------------------------------------------------- | |
4 | ||
5 | Coding style | |
6 | ------------ | |
7 | ||
8 | This project is programmed using the Linux kernel coding style: | |
9 | ||
10 | https://www.kernel.org/doc/html/latest/process/coding-style.html | |
11 | ||
12 | Please use the same style for any code contributions, thanks! | |
13 | ||
14 | ||
15 | Contributions | |
16 | ------------- | |
17 | ||
18 | - In order to contribute you should ideally clone the git repository and | |
19 | let us know (preferably via IRC, or via the mailing list) from where to | |
20 | pull/review your changes. You can use github.com, or any other public git | |
21 | hosting site. | |
22 | ||
23 | - Alternatively, patches can be sent to the development mailinglist at | |
24 | sigrok-devel@lists.sourceforge.net (please subscribe to the list first). | |
25 | ||
26 | https://lists.sourceforge.net/lists/listinfo/sigrok-devel | |
27 | ||
28 | ||
29 | Adding a new hardware driver | |
30 | ---------------------------- | |
31 | ||
32 | The simple, scripted way (recommended): | |
33 | --------------------------------------- | |
34 | ||
35 | Use the 'new-driver' script from the sigrok-util repo: | |
36 | ||
37 | $ git clone git://sigrok.org/sigrok-util | |
38 | $ cd sigrok-util/source | |
39 | $ ./new-driver "Tondaj SL-814" | |
40 | ||
41 | The example above generates a patch file against the current libsigrok | |
42 | development git tree which adds a simple "stub" driver for your device | |
43 | (the Tondaj SL-814 sound level meter in this case). | |
44 | ||
45 | You can apply it like this: | |
46 | ||
47 | $ cd libsigrok | |
48 | $ git am 0001-tondaj-sl-814-Initial-driver-skeleton.patch | |
49 | ||
50 | You can now edit the files in src/hardware/tondaj-sl-814 as needed | |
51 | and implement your driver based on the skeleton files there. That means your | |
52 | patch submission later will consist of at least two patches: the initial one | |
53 | adding the skeleton driver, and one or more additional patches that actually | |
54 | implement the respective driver code. | |
55 | ||
56 | ||
57 | The manual way: | |
58 | --------------- | |
59 | ||
60 | This is a rough overview of what you need to do in order to add a new driver | |
61 | (using the Tondaj SL-814 device as example). It's basically what the | |
62 | 'new-driver' script (see above) does for you: | |
63 | ||
64 | - Makefile.am: Add HW_TONDAJ_SL_814 and add to libsigrok_la_SOURCES. | |
65 | - configure.ac: Add a DRIVER() and DRIVER2() call. | |
66 | - src/drivers.c: Add a tondaj_sl_814_driver_info entry in two places. | |
67 | - src/hardware/tondaj-sl-814/ directory: Add api.c, protocol.c, protocol.h. | |
68 | ||
69 | See existing drivers or the 'new-driver' output for the details. | |
70 | ||
71 | ||
72 | Random notes | |
73 | ------------ | |
74 | ||
75 | - Don't do variable declarations in compound statements, only at the | |
76 | beginning of a function. | |
77 | ||
78 | - Generally avoid assigning values to variables at declaration time, | |
79 | especially so for complex and/or run-time dependent values. | |
80 | ||
81 | - Consistently use g_*malloc() / g_*malloc0(). Do not use standard | |
82 | malloc()/calloc() if it can be avoided (sometimes other libs such | |
83 | as libftdi can return malloc()'d memory, for example). | |
84 | ||
85 | - Always properly match allocations with the proper *free() functions. If | |
86 | glib's g_*malloc()/g_*malloc0() was used, use g_free() to free the | |
87 | memory. Otherwise use standard free(). Never use the wrong function! | |
88 | ||
89 | - We assume that "small" memory allocations (< 1MB) will always succeed. | |
90 | Thus, it's fine to use g_malloc() or g_malloc0() for allocations of | |
91 | simple/small structs and such (instead of using g_try_malloc()), and | |
92 | there's no need to check the return value. | |
93 | ||
94 | Do use g_try_malloc() or g_try_malloc0() for large (>= 1MB) allocations | |
95 | and check the return value. | |
96 | ||
97 | - You should never print any messages (neither to stdout nor stderr nor | |
98 | elsewhere) "manually" via e.g. printf() or g_log() or similar functions. | |
99 | Only sr_err()/sr_warn()/sr_info()/sr_dbg()/sr_spew() should be used. | |
100 | ||
101 | - Use glib's gboolean / TRUE / FALSE for boolean types consistently. | |
102 | Do not use <stdbool.h> and its true / false, and do not invent private | |
103 | definitions for this either. | |
104 | ||
105 | - Consistently use the same naming convention for #include guards in headers: | |
106 | <PROJECTNAME>_<PATH_TO_FILE>_<FILE> | |
107 | This ensures that all #include guards are always unique and consistent. | |
108 | Example: LIBSIGROK_HARDWARE_MIC_985XX_PROTOCOL_H | |
109 | ||
110 | - Consistently use the same naming convention for API functions: | |
111 | <libprefix>_<groupname>_<action>(). | |
112 | ||
113 | Examples: | |
114 | sr_log_loglevel_set(), sr_log_loglevel_get(), sr_log_handler_set(), | |
115 | sr_log_handler_set_default(), and so on. | |
116 | Or: | |
117 | sr_session_new(), sr_session_destroy(), sr_session_load(), and so on. | |
118 | ||
119 | Getter/setter function names should usually end with "_get" or "_set". | |
120 | Functions creating new "objects" should end with "_new". | |
121 | Functions destroying "objects" should end with "_destroy". | |
122 | Functions adding or removing items (e.g. from lists) should end with | |
123 | either "_add" or "_remove". | |
124 | Functions operating on all items from a list (not on only one of them), | |
125 | should end with "_all", e.g. "_remove_all", "_get_all", and so on. | |
126 | Use "_remove_all" in favor of "_clear" for consistency. | |
127 | ||
128 | - All enums should generally use an explicit start number of 10000. | |
129 | If there are multiple "categories" in the enum entries, each category | |
130 | should be 10000 entries apart from the next one. The start of categories | |
131 | are thus 10000, 20000, 30000, and so on. | |
132 | ||
133 | Adding items to an enum MUST always append to a "category", never add | |
134 | items in the middle of a category. The order of items MUST NOT be changed. | |
135 | Any of the above would break the ABI. | |
136 | ||
137 | The enum item 0 is special and is used as terminator in some lists, thus | |
138 | enums should not use this for "valid" entries (and start at 10000 instead). | |
139 | ||
140 | ||
141 | Doxygen | |
142 | ------- | |
143 | ||
144 | - Use the @ notation for all Doxygen comments (e.g. @param, not \param). | |
145 | ||
146 | - Do not use the @brief tag, it's unnecessary as we use JAVADOC_AUTOBRIEF. | |
147 | ||
148 | - Generally use the following item order in Doxygen comments: | |
149 | - Brief function description (1 line), followed by an empty line. | |
150 | - Optionally, a longer function description (and another empty line). | |
151 | - The list of parameter descriptions (@param). | |
152 | - The return value description (@return or @retval). | |
153 | - An optional @since tag (only for public SR_API functions). | |
154 | - An optional @private tag (for private SR_PRIV functions). | |
155 | ||
156 | - In @param lines, the name of the parameter is followed by a space and | |
157 | then a sentence describing the parameter (starts with a capital letter, | |
158 | ends with a full stop). | |
159 | ||
160 | - In Doxygen comments, put an empty line between the block of @param lines | |
161 | and the final @return line. The @param lines themselves (if there is more | |
162 | than one) are not separated by empty lines. | |
163 | ||
164 | - Mark private functions (SR_PRIV) with /** @private */, so that Doxygen | |
165 | doesn't include them in the output. Functions that are "static" anyway | |
166 | don't need to be marked like this. | |
167 | ||
168 | - Mark private variables/#defines with /** @cond PRIVATE */ and | |
169 | /** @endcond */, so that Doxygen doesn't include them in the output. | |
170 | Variables that are "static" don't need to be marked like this. | |
171 | ||
172 | - Mark all public API functions (SR_API) with a @since tag which indicates | |
173 | in which release the respective function was added (e.g. "@since 0.1.0"). | |
174 | ||
175 | If the function has existed before, but its API changed later, the @since | |
176 | tag should mention only the release when the API last changed. | |
177 | ||
178 | Example: The sr_foo() call was added in 0.1.0, but the API changed in | |
179 | the later 0.2.0 release. The docs should read "@since 0.2.0" in that case. | |
180 | ||
181 | Non-public functions (static ones, and those marked SR_PRIV) don't need | |
182 | to have @since markers. | |
183 | ||
184 | The @since tag should be the last one, i.e. it should come after @param, | |
185 | @return, @see, and so on. | |
186 | ||
187 | - Examples: | |
188 | ||
189 | /** | |
190 | * Tell a hardware driver to scan for devices. | |
191 | * | |
192 | * In addition to the detection, the devices that are found are also | |
193 | * initialized automatically. On some devices, this involves a firmware upload, | |
194 | * or other such measures. | |
195 | * | |
196 | * The order in which the system is scanned for devices is not specified. The | |
197 | * caller should not assume or rely on any specific order. | |
198 | * | |
199 | * Before calling sr_driver_scan(), the user must have previously initialized | |
200 | * the driver by calling sr_driver_init(). | |
201 | * | |
202 | * @param[in] driver The driver that should scan. Must be a pointer to one of | |
203 | * the entries returned by sr_driver_list(). Must not be NULL. | |
204 | * @param[in] options List of 'struct sr_hwopt' options to pass to the driver's | |
205 | * scanner. Can be NULL/empty. | |
206 | * | |
207 | * @return A GSList * of 'struct sr_dev_inst', or NULL if no devices were | |
208 | * found (or errors were encountered). This list must be freed by the | |
209 | * caller using g_slist_free(), but without freeing the data pointed | |
210 | * to in the list. | |
211 | * | |
212 | * @since 0.2.0 | |
213 | */ | |
214 | ||
215 | /** | |
216 | * Query value of a configuration key at the given driver or device instance. | |
217 | * | |
218 | * @param[in] driver The sr_dev_driver struct to query. Must not be NULL. | |
219 | * @param[in] sdi (optional) If the key is specific to a device, this must | |
220 | * contain a pointer to the struct sr_dev_inst to be checked. | |
221 | * Otherwise it must be NULL. If sdi is != NULL, sdi->priv must | |
222 | * also be != NULL. | |
223 | * @param[in,out] data Pointer to a GVariant where the value will be stored. | |
224 | * Must not be NULL. The caller is given ownership of the GVariant | |
225 | * and must thus decrease the refcount after use. However if | |
226 | * this function returns an error code, the field should be | |
227 | * considered unused, and should not be unreferenced. | |
228 | * | |
229 | * @retval SR_OK Success. | |
230 | * @retval SR_ERR Error. | |
231 | * @retval SR_ERR_ARG The driver doesn't know that key, but this is not to be | |
232 | * interpreted as an error by the caller; merely as an indication | |
233 | * that it's not applicable. | |
234 | * | |
235 | * @since 0.3.0 | |
236 | * @private | |
237 | */ | |
238 | ||
239 | ||
240 | Testsuite | |
241 | --------- | |
242 | ||
243 | You can run the libsigrok testsuite using: | |
244 | ||
245 | $ make check | |
246 | ||
247 | ||
248 | Release engineering | |
249 | ------------------- | |
250 | ||
251 | See | |
252 | ||
253 | http://sigrok.org/wiki/Developers/Release_process | |
254 | ||
255 | for a list of items that need to be done when releasing a new tarball. | |
256 |