Provisions for running on systems where nimble is already built

[chrysn]

I'd like to use these crates (mainly apache-nimble, and trouble building on it) on RIOT OS; I figure the situation with other C RTOSes might be similar when they come to a point where applications and modules can be built in Rust. Nimble is already built as part of RIOT OS (currently 1.5, but 1.8 is WIP), so I'd need to apply a few configurable changes.

As far as I can assess things so far (I got things to build but did not test running), this will need:

• A way to switch raw from apache-riot-sys to using re-exports of the OS's header generation.
• Minor generalizations due to build flags now controlled by someone else. In particular, when packed enums are enabled, OsError's repr changes.
• The build script essentially needs an "off" switch -- there's another component in this case that takes care of linking, and that is by static linking in this case.
• Actually running the controller tasks likely needs to be feature gated: In RIOT, this is already being run in a thread.

I should have a draft PR ready soon-ish, but at this point I'm unsure: What is the intended scope of the apache-nimble crate? I plan on using this with trouble sitting on top of it, so the part of the apache-nimble crate that is not modified is the impl bt_hci::controller::Controller for NimbleController -- is that the core of apache-nimble (in which case I do think that it makes sense to allow disabling the build and link parts), or rather something that would be shared as an external component (so it may make sense to split that into a sharable component)?

[Univa]

If I'm understanding this correctly, we essentially have the following scenario:

• Instead of building+linking NimBLE via apache-nimble/build.rs, you want to build it and link it yourself.
• RIOT OS already handles the execution of the controller tasks.
• You would still like to use the high-level bindings provided via apache-nimble

In that case, yes, I think for the most part, those points you listed are correct.

A way to switch raw from apache-riot-sys to using re-exports of the OS's header generation.

The build script essentially needs an "off" switch -- there's another component in this case that takes care of linking, and that is by static linking in this case.

(assuming you meant apache-nimble-sys)

This makes sense to me. My initial thought to do this would be to add an "empty" port layer (maybe a port-layer-custom feature flag or something along those lines): essentially just disables the build scripts. Perhaps you can use an environment variable so that apache-nimble-sys can generate the bindings from your version of NimBLE (as opposed to the one in this repo).

Actually running the controller tasks likely needs to be feature gated: In RIOT, this is already being run in a thread.

For this point in particular, I don't know if we need to add another feature flag. In the example, we use NimbleController::create_task to run the controller. If RIOT already handles the controller tasks itself, you can probably just omit that create_task call, and continue to use NimbleController with trouble.

What is the intended scope of the apache-nimble crate?

The scope of that crate isn't super well-defined, besides being "higher-level abstractions on top of the low-level bindings provided by apache-nimble-sys". It might be confusing that the apache-nimble/build.rs does actually compile and link the NimBLE code, but it's mainly like that because I thought it would be easier if the crate just did the building+linking itself (as opposed to users of the apache-nimble crate needing to compile and link NimBLE themselves). For now, I'm okay with the ability to disable the building+linking parts. I think the idea of splitting the high-level API is interesting, but I'm not sure right now what that would look like, or if it's even worth pursuing. Would need to give it some more thought.

[chrysn]

Yes, we have the same scenario in mind. Thanks, I'll give it a try with a PR, then.

Actually running the controller tasks likely needs to be feature gated

I don't know if we need to add another feature flag

I'll give that another look. IIRC, the provided implementations called functions that for some reason were not even available. Might be that I found what caused that and fixed it differently down the line; I'll see that once I more systematically collect all the things that are currently spread across my checkouts.