summaryrefslogtreecommitdiffstats
path: root/core/uemis-downloader.c
diff options
context:
space:
mode:
authorGravatar Linus Torvalds <torvalds@linux-foundation.org>2017-06-27 11:59:11 -0700
committerGravatar Linus Torvalds <torvalds@linux-foundation.org>2017-06-27 13:58:15 -0700
commitd01b7bf89167ff8ab40c4b663398816da678084a (patch)
tree33b5b554b6ec8ed42febc46ba4a560b06ba52107 /core/uemis-downloader.c
parente79bede0aa5b3bd169a29dbb907002d6ac717c6e (diff)
downloadsubsurface-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.c2
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];