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