This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
This addresses (parts of) bug #802.
The sigrok core needs a list of all available drivers. Currently this list
is manually maintained by updating a global list whenever a driver is added
or removed.
Introduce a new special section that contains the list of all drivers. The
SR_REGISTER_DEV_DRIVER() and SR_REGISTER_DEV_DRIVER_LIST() macro is used to
add drivers to this new list. This is done by placing the pointers to the
driver into a special section. Since nothing else is in this section it is
known that it is simply a list of driver pointers and the core can iterate
over it as if it was an array.
The advantage of this approach is that the code necessary to add a driver
to the list is completely contained to the driver source and it is no
longer necessary to maintain a global list. If a driver is built it will
automatically appear in the list, if it is not built in won't. This means
that the list is always correct, whereas the previous approach used ifdefs
in the global driver list file which could get out-of-sync with the actual
condition when the driver was built.
Any sr_dev_driver structs that are no longer used outside the driver module
are marked as static.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The resource API provides a generic means for accessing resources
that are bundled with sigrok, such as device firmware files. Since
the manner of resource bundling is platform-dependent, users of
libsigrok may override the functions used to open, close and read
a resource. The default implementation accesses resources as files
located in one of the XDG data directories or a directory defined
at compile time.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
Move the include flags for files in the source tree from
configure.ac to Makefile.am where they belong. Also use
AM_CPPFLAGS instead of CFLAGS/CXXFLAGS to make sure the
files in the build/source tree are always picked up first.
Also, remove the include/libsigrok sub-directory from the
search path, thereby making the <libsigrok/> prefix mandatory
when building libsigrok itself. This matches the convention
already imposed on users of the library.
../src/backend.c: In function 'sr_init':
../src/backend.c:435:1: warning: label 'done' defined but not used [-Wunused-label]
done:
^
../src/device.c: In function 'sr_dev_inst_connid_get':
../src/device.c:525:7: warning: unused variable 'connection_id' [-Wunused-variable]
char connection_id[64];
^
../src/device.c:524:20: warning: unused variable 'b' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:17: warning: unused variable 'a' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:14: warning: unused variable 'i' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:9: warning: unused variable 'cnt' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:6: warning: unused variable 'r' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:523:22: warning: unused variable 'drvc' [-Wunused-variable]
struct drv_context *drvc;
^
This requires sr_hw_cleanup_all() and sanity_check_all_drivers()
to also take a context.
The (runtime) generation of the driver list now happens in sr_init()
and sr_driver_list() always returns that pre-generated list. This fixes
a segfault when (correctly) invoking multiple sr_init() and sr_exit()
calls with different contexts (caught by the unit tests).
This fixes bug #565.
Use g_malloc0() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Don't always sanity-check parameters for non-public (SR_PRIV)
functions, we require the developers to invoke them correctly.
This allows further error handling simplifications.
This signifies to the module instance no more input will come. This
will cause the module to process any data it may have buffered. The
SR_DF_END packet will also typically be sent at this time.
Uwe Hermann
Aurelien Jacobs
Lars-Peter Clausen
Martin Ling
Daniel Elstner
Bert Vermeulen