From d01b7bf89167ff8ab40c4b663398816da678084a Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 27 Jun 2017 11:59:11 -0700 Subject: 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 --- core/libdivecomputer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'core/libdivecomputer.c') diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c index 2f0a303e3..7d41b9d06 100644 --- a/core/libdivecomputer.c +++ b/core/libdivecomputer.c @@ -605,7 +605,7 @@ static void parse_string_field(struct dive *dive, dc_field_string_t *str) } #endif -static dc_status_t libdc_header_parser(dc_parser_t *parser, struct device_data_t *devdata, struct dive *dive) +static dc_status_t libdc_header_parser(dc_parser_t *parser, dc_user_device_t *devdata, struct dive *dive) { dc_status_t rc = 0; dc_datetime_t dt = { 0 }; @@ -1091,11 +1091,11 @@ const char *do_libdivecomputer_import(device_data_t *data) #if defined(SSRF_CUSTOM_IO) if (data->bluetooth_mode) { #if defined(BT_SUPPORT) && defined(SSRF_CUSTOM_IO) - rc = dc_context_set_custom_io(data->context, get_qt_serial_ops()); + rc = dc_context_set_custom_io(data->context, get_qt_serial_ops(), data); #endif #ifdef SERIAL_FTDI } else if (!strcmp(data->devname, "ftdi")) { - rc = dc_context_set_custom_io(data->context, &serial_ftdi_ops); + rc = dc_context_set_custom_io(data->context, &serial_ftdi_ops, data); INFO(0, "setting up ftdi ops"); #else INFO(0, "FTDI disabled"); -- cgit v1.2.3-70-g09d2