Scubapro Galileo 2 (G2)

[Linus Torvalds]

On Mon, Jun 26, 2017 at 11:37 PM, Linus Torvalds
<torvalds at 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