anchao commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384575947
> @anchao I agree 100% with everything you said, my only concern is assuming
CONFIG_BT is ZBLUE you are removing the chance to let the NuttX native
Bluetooth stack to become the default CONFIG_BT in the future.
>
> This is why I suggested using CONFIG_ZBLUE, just like we have
CONFIG_NINBLE.
@acassis
I understand your concern, but I would like to clarify one point.
If this were only about renaming directories, moving files, or changing the
internal build/layout structure, I would have no problem with that. I have
already adjusted the layout several times based on review feedback.
What I am trying to avoid is exposing the implementation identity in the
public
Kconfig or API naming. For developers who are familiar with Bluetooth stacks
in
Linux or Zephyr, CONFIG_BT is the natural and expected entry point for
Bluetooth
support. Having the main host stack option named after a specific internal
implementation, such as CONFIG_ZBLUE, makes the configuration less intuitive
and
harder to understand from a Bluetooth developer's point of view.
In my view, CONFIG_BT should mean "Bluetooth support", not necessarily "this
is
forever tied to one implementation name". The implementation can still live
under libs/zblue internally, but the user-facing Kconfig entry should remain
the
common Bluetooth entry.
At this stage, CONFIG_BT does not conflict with the existing native NuttX
Bluetooth Kconfig in a practical way. Also, our plan is to rework the
current
NuttX Bluetooth architecture quite soon, possibly in the next couple of
weeks.
The intention is for CONFIG_BT to become the common Bluetooth host entry and
to
replace the current incomplete native stack path. This work will also
include
the integration with the existing Bluetooth network support and btsak, and
use
ZBlue to provide the L2CAP/host implementation inside NuttX.
So I do not see CONFIG_BT as taking away the future of the native stack.
Instead,
I see it as defining the common Bluetooth entry point that the improved
NuttX
Bluetooth architecture will use.
Maybe we can also ask projects that are currently using NimBLE(cc
@raiden00pl ): if NuttX
provides a complete and well-maintained BLE implementation in the kernel,
would
they still prefer to use a third-party Bluetooth stack? I think that
feedback
would be useful for deciding the long-term direction.
--
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]
