Scubapro Galileo 2 (G2)

[Linus Torvalds]

On Mon, Jun 26, 2017 at 11:37 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> Anyway, right now that "custom_io_t" only has the packet size as a way
> to discriminate with, but that clearly is not sufficient. But neither
> is it good enough to say what type it is - it's also not sufficient to
> say "USB vs USB HID vs BLE". Because it turns out that within BLE
> there are variations, and obviously within USB there are certainly
> possibilities for variations way past just the USBHID vs "random
> vendor-specific USB" case.

Btw, that may have come off the wrong way - I do *not* think that the
particular protocol should even be enumerated or described
particularly well at all using some generic descriptors.

No, in many ways I'm arguing for the reverse: not to describe things
very much at all, but instead just let each "custom_io_t" do its own
thing, and just have a "void *" that the particular transport fills in
with *its* particular details. And those details will be very
different for bluetooth than they will be for USB.

And I already ended up chaining these custom_io_t's together: the way
I did the Shearwater Perdix was to use the "rfcomm" serial interface
to expose the serial side, but then when using BLE GATT, literally
chaining that serial side though two levels of custom_io_t: the first
level does the buffering to make it look like a serial line, and the
second level is the regular BLE GATT packetization for the actual IO.

It's pretty hacky, and it's not some kind of truly generic "streams"
thing that is designed to chain, but more of just a special case a
"turn one interface into another" chain, but it works. And it largely
avoids exposing the details of one level to another, and it's not
passing any odd level descriptors around, because the custom_io_t
itself *is* the descriptor and contains the knowledge of what it's
doing and who it is acting to.

              Linus