2012-10-16 09:24:03 +00:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
HACKING
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Coding style
|
|
|
|
------------
|
|
|
|
|
|
|
|
This project is programmed using the Linux kernel coding style, see
|
|
|
|
http://lxr.linux.no/linux/Documentation/CodingStyle for details.
|
|
|
|
|
|
|
|
Please use the same style for any code contributions, thanks!
|
|
|
|
|
|
|
|
|
|
|
|
Contributions
|
|
|
|
-------------
|
|
|
|
|
|
|
|
- Patches should be sent to the development mailinglist at
|
|
|
|
sigrok-devel@lists.sourceforge.net (please subscribe to the list first).
|
|
|
|
|
|
|
|
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
|
|
|
|
|
|
|
|
- Alternatively, you can also clone the git repository and let us know
|
|
|
|
from where to pull/review your changes. You can use gitorious.org,
|
|
|
|
github.com, or any other public git hosting site.
|
|
|
|
|
|
|
|
|
2012-10-25 21:42:20 +00:00
|
|
|
Adding a new hardware driver
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
The simple, scripted way (recommended):
|
|
|
|
---------------------------------------
|
|
|
|
|
|
|
|
Use the 'new-driver' script from the sigrok-util repo:
|
|
|
|
|
|
|
|
$ git clone git://sigrok.org/sigrok-util
|
|
|
|
$ cd sigrok-util/source
|
|
|
|
$ ./new-driver "Tondaj SL-814"
|
|
|
|
|
|
|
|
The example above generates a patch file against the current libsigrok
|
|
|
|
development git tree which adds a simple "stub" driver for your device
|
|
|
|
(the Tondaj SL-814 sound level meter in this case).
|
|
|
|
|
|
|
|
You can apply it like this:
|
|
|
|
|
|
|
|
$ cd libsigrok
|
|
|
|
$ git am 0001-tondaj-sl-814-Initial-driver-skeleton.patch
|
|
|
|
|
|
|
|
You can now edit the files in the hardware/tondaj-sl-814 directory as needed.
|
|
|
|
|
|
|
|
|
|
|
|
The manual way:
|
|
|
|
---------------
|
|
|
|
|
|
|
|
This is a rough overview of what you need to do in order to add a new driver
|
|
|
|
(using the Tondaj SL-814 device as example). It's basically what the
|
|
|
|
'new-driver' script (see above) does for you:
|
|
|
|
|
|
|
|
- configure.ac:
|
|
|
|
- Add an --enable-tondaj-sl-814 option.
|
|
|
|
- Add "hardware/tondaj-sl-814/Makefile" to the AC_CONFIG_FILES list.
|
|
|
|
- Add and entry for the device in the "Enabled hardware drivers" list
|
|
|
|
at the bottom of the file.
|
|
|
|
- hardware/Makefile.am: Add "tondaj-sl-814" to the SUBDIRS variable.
|
|
|
|
- hwdriver.c: Add a tondaj_sl_814_driver_info entry in two places.
|
|
|
|
- hardware/tondaj-sl-814/ directory: Add the following files:
|
|
|
|
Makefile.am, api.c, protocol.c, protocol.h
|
|
|
|
|
|
|
|
See existing drivers or the 'new-driver' output for the details.
|
|
|
|
|
|
|
|
|
2012-10-16 09:24:03 +00:00
|
|
|
Random notes
|
|
|
|
------------
|
|
|
|
|
|
|
|
- Consistently use g_try_malloc() / g_try_malloc0(). Do not use standard
|
|
|
|
malloc()/calloc() if it can be avoided (sometimes other libs such
|
|
|
|
as libftdi can return malloc()'d memory, for example).
|
|
|
|
|
|
|
|
- Always properly match allocations with the proper *free() functions. If
|
|
|
|
glib's g_try_malloc()/g_try_malloc0() was used, use g_free() to free the
|
|
|
|
memory. Otherwise use standard free(). Never use the wrong function!
|
|
|
|
|
|
|
|
- Never use g_malloc() or g_malloc0(). These functions do not return NULL
|
|
|
|
if not enough memory is available but rather lead to an exit() or segfault
|
2012-10-16 12:48:39 +00:00
|
|
|
instead. This behaviour is not acceptable for libraries.
|
2012-10-16 09:24:03 +00:00
|
|
|
Use g_try_malloc()/g_try_malloc0() instead and check the return value.
|
|
|
|
|
2012-10-16 12:48:39 +00:00
|
|
|
- You should never print any messages (neither to stdout nor stderr nor
|
2012-10-16 09:24:03 +00:00
|
|
|
elsewhere) "manually" via e.g. printf() or g_log() or similar functions.
|
|
|
|
Only sr_err()/sr_warn()/sr_info()/sr_dbg()/sr_spew() should be used.
|
|
|
|
|
|
|
|
- Use glib's gboolean / TRUE / FALSE for boolean types consistently.
|
|
|
|
Do not use <stdbool.h> and its true / false, and do not invent private
|
|
|
|
definitions for this either.
|
|
|
|
|
|
|
|
- Consistently use the same naming convention for #include guards in headers:
|
|
|
|
<PROJECTNAME>_<PATH_TO_FILE>_<FILE>
|
|
|
|
This ensures that all #include guards are always unique and consistent.
|
|
|
|
Examples: LIBSIGROK_LIBSIGROK_H, LIBSIGROK_HARDWARE_ASIX_SIGMA_ASIX_SIGMA_H
|
|
|
|
|
|
|
|
- Consistently use the same naming convention for API functions:
|
|
|
|
<libprefix>_<groupname>_<action>().
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
sr_log_loglevel_set(), sr_log_loglevel_get(), sr_log_handler_set(),
|
|
|
|
sr_log_handler_set_default(), and so on.
|
|
|
|
Or:
|
|
|
|
sr_session_new(), sr_session_destroy(), sr_session_load(), and so on.
|
|
|
|
|
|
|
|
Getter/setter function names should usually end with "_get" or "_set".
|
|
|
|
Functions creating new "objects" should end with "_new".
|
|
|
|
Functions destroying "objects" should end with "_destroy".
|
|
|
|
Functions adding or removing items (e.g. from lists) should end with
|
|
|
|
either "_add" or "_remove".
|
|
|
|
Functions operating on all items from a list (not on only one of them),
|
|
|
|
should end with "_all", e.g. "_remove_all", "_get_all", and so on.
|
|
|
|
Use "_remove_all" in favor of "_clear" for consistency.
|
|
|
|
|
2012-10-19 08:07:22 +00:00
|
|
|
|
|
|
|
Doxygen
|
|
|
|
-------
|
|
|
|
|
2012-10-16 09:24:03 +00:00
|
|
|
- In Doxygen comments, put an empty line between the block of @param lines
|
|
|
|
and the final @return line. The @param lines themselves (if there is more
|
|
|
|
than one) are not separated by empty lines.
|
|
|
|
|
2012-10-19 08:07:22 +00:00
|
|
|
- Mark private functions (SR_PRIV) with /** @private */, so that Doxygen
|
|
|
|
doesn't include them in the output. Functions that are "static" anyway
|
|
|
|
don't need to be marked like this.
|
|
|
|
|
|
|
|
- Mark private variables/#defines with /** @cond PRIVATE */ and
|
|
|
|
/** @endcond */, so that Doxygen doesn't include them in the output.
|
|
|
|
Variables that are "static" don't need to be marked like this.
|
|
|
|
|
2012-10-16 09:24:03 +00:00
|
|
|
|
|
|
|
Release engineering
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
See
|
|
|
|
|
|
|
|
http://sigrok.org/wiki/Developers/Release_process
|
|
|
|
|
|
|
|
for a list of items that need to be done when releasing a new tarball.
|
|
|
|
|