On Mon, Jun 26, 2017 at 11:37 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
The older "customserial" protocol made the big mistake of not passing its own IO data descriptor around, just passing that "fill in this 'void **userdata' thing", and it works as long as you really *just* look like serial (which rfcomm does).
But immediately when you need to add your own transport quirks in there, you need something more.
So I sent Dirk the pull request for my SSRF_CUSTOM_IO v2 code, which updates the custom serial parts to pass along the IO pointer, and also adds a opaque (as far as libdivecomputer is concerned) "dc_user_device_t" field to the IO model.
That allows me to pass down not just the IO functions, but also the "what device am I trying to download from" information, because the IO model gets filled in early, and gets passed around to all the openm code and IO accessor functions.
That, in turn, allows me to have different bluetooth logic for open and IO based on the device I'm downloading from. Which I need, since the rules are different for a Shearwater device than for a Suunto one.
It's not pretty, but then bluetooth LE really isn't pretty. It's very much a "designed by committee" thing, and (similarly to USB, presumably for similar reasons), bluetooth LE was explicitly designed to *not* just have a standardized serial protocol.
Morons. USB did the exact same thing, and I think the reasons are the same: both design committees wanted to explicitly avoid "transparent serial emulation" simply because serial can be used for anything, and they wanted to *describe* each protocol.
Never mind the fact that reality trumps the poor brains of committee people, and people want to do serial communications over new protocols, so they all then just make it happen anyway, but do it in some crazy vendor-specific manner.
So instead of having a nice clean architected serial line emulation of USB or over BLE, we have ugly shit-for-brains vendor-specific ones that are different and often subtly broken.
Yay for committee standards - those committees really showed people how much better things are when you try to force people to all do their own described protocols rather than use a standard serial one.
Linus