anchao commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6416584086
> @anchao
>
> Good point, I think if we have a similar CONFIG_ZBLUE_ENABLED,
CONFIG_NIMBLE_ENABLED, etc, we could keep the generic CONFIG_BT_* in place and
reuse it between stacks.
>
> If you decide to modify to follow this approach I am fine with it.
@acassis Thanks, I think this is a good compromise.
I updated the PR to add an explicit `CONFIG_ZBLUE_ENABLED` option for
selecting
the ZBlue Bluetooth host stack. With this change, users can now clearly see
and
select the ZBlue stack itself, instead of having the stack selection hidden
behind the generic Bluetooth feature namespace.
At the same time, I kept the existing Bluetooth feature options under the
generic `CONFIG_BT_*` naming. My intention is that `CONFIG_ZBLUE_ENABLED`
identifies the implementation/stack choice, while the `CONFIG_BT_*` options
continue to describe Bluetooth features and profiles rather than exposing
the
implementation name in every feature symbol.
So the configuration model is now:
- `CONFIG_ZBLUE_ENABLED`: select the ZBlue Bluetooth host stack
- `CONFIG_BT_*`: Bluetooth features, roles, profiles, services, Mesh, LE
Audio,
Classic, buffer sizing, and related host options
Thanks for the suggestion. I think this keeps the stack selection explicit
while
preserving the familiar Bluetooth feature naming for developers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
