4 ms·

> Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec. But there needs to be a spec of a protocol in order to enable

> Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec. But there needs to be a spec of a protocol in order to enable interop? The question whether it is baked into the protocol stack or distributed separately as a library doesn’t seem that much of a distinction. What is important is certification, because otherwise connecting different manufacturers would never work smoothly.

xyzzy_plugh 3y ago
You're right, and if you're implementing a profile for a widget chances are you can stumble your way through the spec and get something that mostly works. The problem is that the cross product of hardware on the sending and receiving sides leaves sufficient gaps that you will be banging your head against the wall trying to figure out why a profile isn't working and it's because Vendor's part doesn't implement the spec properly. I sometimes wonder what a world where every radio is a software-defined radio and we can all just update our full Bluetooth implementation alongside our OS. Instead it's the worst case of "actually another CPU with closed source blob firmware" and so we're absolutely left stranded. I think what is being advocated here is moving profiles outside the implementation, into libraries we can port around, or e.g. the kernel somewhere, and I think that is indeed a step in the right direction.
- MichaelZuo 3y ago
  How would you implement such a mechanism without introducing a lot of overhead?
  - sampullman 3y ago
    Where's the overhead? Depending on your system the whole thing could be zero copy down to the DMA buffer. It's just a read/write protocol with a separate channel for commands.
    - MichaelZuo 3y ago
      I'm not an expert on implementing Bluetooth in real life products, but something tells me it will be a bit more complex then that.
      - sampullman 3y ago
        At the HCI level the Bluetooth protocol is sane enough, it's straightforward to provide a zero-copy interface to the L2CAP layer if you're writing your own host stack. A product I worked on in the past used a serial connection over Bluetooth to Android/iOS apps. In order to communicate to an Apple device, the layers roughly looked like: Radio -> L2CAP -> RFCOMM -> iAP2 The RFCOMM/iAP2 part were redundant. It's understandable that Apple wanted to certify devices, but implementing that as a thin layer over L2CAP and making the profiles on top optional would have made the system much simpler. There may have been historical reliability concerns on the Bluetooth side that justifies what they ended up with, I'm not sure.
sampullman 3y ago
Absolutely, certification is necessary for manufacturer interop. But I do think separating profiles from the stack would have saved a lot of headache, especially in the early days. Each implementation had tons of bugs, and it was often impossible to do anything about it unless you were an OS/module vendor, or were otherwise in a position to deploy your own HCI firmware.
- MrBuddyCasino 3y ago
  This cuts both ways: a vendor willing to fix things can if it is just about updating a library, but then a vendor that doesn't give a crap and who will never roll out fixes leaves a user stranded. But if the fix is part of the OS, every user will benefit from it, regardless of his device manufacturer. I think in practise we have a mix anyway - manufacturers already license BT stacks from a few vendors, and don't develop them themselves.

xyzzy_plugh 3y ago

You're right, and if you're implementing a profile for a widget chances are you can stumble your way through the spec and get something that mostly works. The problem is that the cross product of hardware on the sending and receiving sides leaves sufficient gaps that you will be banging your head against the wall trying to figure out why a profile isn't working and it's because Vendor's part doesn't implement the spec properly. I sometimes wonder what a world where every radio is a software-defined radio and we can all just update our full Bluetooth implementation alongside our OS. Instead it's the worst case of "actually another CPU with closed source blob firmware" and so we're absolutely left stranded. I think what is being advocated here is moving profiles outside the implementation, into libraries we can port around, or e.g. the kernel somewhere, and I think that is indeed a step in the right direction.

MichaelZuo 3y ago
How would you implement such a mechanism without introducing a lot of overhead?
- sampullman 3y ago
  Where's the overhead? Depending on your system the whole thing could be zero copy down to the DMA buffer. It's just a read/write protocol with a separate channel for commands.
  - MichaelZuo 3y ago
    I'm not an expert on implementing Bluetooth in real life products, but something tells me it will be a bit more complex then that.
    - sampullman 3y ago
      At the HCI level the Bluetooth protocol is sane enough, it's straightforward to provide a zero-copy interface to the L2CAP layer if you're writing your own host stack. A product I worked on in the past used a serial connection over Bluetooth to Android/iOS apps. In order to communicate to an Apple device, the layers roughly looked like: Radio -> L2CAP -> RFCOMM -> iAP2 The RFCOMM/iAP2 part were redundant. It's understandable that Apple wanted to certify devices, but implementing that as a thin layer over L2CAP and making the profiles on top optional would have made the system much simpler. There may have been historical reliability concerns on the Bluetooth side that justifies what they ended up with, I'm not sure.

sampullman 3y ago

Absolutely, certification is necessary for manufacturer interop. But I do think separating profiles from the stack would have saved a lot of headache, especially in the early days. Each implementation had tons of bugs, and it was often impossible to do anything about it unless you were an OS/module vendor, or were otherwise in a position to deploy your own HCI firmware.

MrBuddyCasino 3y ago
This cuts both ways: a vendor willing to fix things can if it is just about updating a library, but then a vendor that doesn't give a crap and who will never roll out fixes leaves a user stranded. But if the fix is part of the OS, every user will benefit from it, regardless of his device manufacturer. I think in practise we have a mix anyway - manufacturers already license BT stacks from a few vendors, and don't develop them themselves.