nimble support

[FlorianLudwig]

Hi @cyberman54 / @oliverbrandmueller

I would like to suggest to add back a build-time switch to toggle between nimble.

The use-case is we would like to use the library in a context where we also use BLE via nimble. With nimble-based libpax it is possible to use nimble while also having libpax running.

Is that something you would accept in libpax?

[oliverbrandmueller]

Though this brings in a little more complexity, I'd accept this approach. Also for future use cases, which might imply to use BLE for other purposes in the same device, this opens up an easy and fast way to imlement this.

• the build switch MUST completely disable using/linking the nimble library, if unused (regading: code size, security issues)
• If possibe, the change SHOULD be backwards compatible, so we don't need a major version bump. However, I would accept a version bump, if too many workarounds would be needed.

[cyberman54]

Basically, the Bluetooth protocol stack splits into two parts: a “controller stack” and a “host stack”. Since the first major refactoring, libpax currently needs only a bluetooth controller wit VHCI interface to run, it does not need a host stack (e.g. nimBLE or Bluedroid).

We should keep this structure maintained, because it has a good fit for embedded systems, i.e. it allows to implement a bluetooth host stack on a different device than that which libpax is running on.

Thus, if we add an option to add a host stack, this should be implemented in a manner that it "tops on". If this is not possible, the code better should be forked into a separate branch.

[FlorianLudwig]

Thanks for the quick replies :)

@oliverbrandmueller both of your requirements should be possible to be met.

@cyberman54

We should keep this structure maintained, because it has a good fit for embedded systems, i.e. it allows to implement a bluetooth host stack on a different device than that which libpax is running on.

As far as I know that is currently not possible (in a clean way). The host stack operates under the assumption it is the only one issuing commands to the hardware. So only one host stack can be active at any time. With libpax talking directly to the hardware via VHCI it basically acts like a host stack, making it error prone to run another host stack in parallel.

[cyberman54]

That's true. There is no kind of thread safe logic. And the VHCI is working asynchronous, what makes things more complex. Thus, it won't make sense to simply top up a Bluetooth stack. So we need an integration.