diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2017-06-27 11:59:11 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2017-06-27 13:58:15 -0700 |
commit | d01b7bf89167ff8ab40c4b663398816da678084a (patch) | |
tree | 33b5b554b6ec8ed42febc46ba4a560b06ba52107 /core/uemis-downloader.c | |
parent | e79bede0aa5b3bd169a29dbb907002d6ac717c6e (diff) | |
download | subsurface-d01b7bf89167ff8ab40c4b663398816da678084a.tar.gz |
Switch over to SSRF_CUSTOM_IO v2
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'core/uemis-downloader.c')
-rw-r--r-- | core/uemis-downloader.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/core/uemis-downloader.c b/core/uemis-downloader.c index e65c1fd46..7c91f985a 100644 --- a/core/uemis-downloader.c +++ b/core/uemis-downloader.c @@ -1120,7 +1120,7 @@ static void get_uemis_divespot(const char *mountpath, int divespot_id, struct di } } -static bool get_matching_dive(int idx, char *newmax, int *uemis_mem_status, struct device_data_t *data, const char *mountpath, const char deviceidnr) +static bool get_matching_dive(int idx, char *newmax, int *uemis_mem_status, dc_user_device_t *data, const char *mountpath, const char deviceidnr) { struct dive *dive = data->download_table->dives[idx]; char log_file_no_to_find[20]; |