acassis commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384635046
> > @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. @anchao but NuttX Kconfig is not 1:1 to Linux or Zephyr (it shouldn't be). So I think CONFIG_BT should mean BT/BLE supoort and then we have the stack used: CONFIG_BT_NIMBLE, CONFIG_BT_ZBLUE, etc. Does it makes more sense? If we used CONFIG_BT to compile the ZBLUE stack only, it will be difficult to repurpose it to other stack later. So I think separating CONFIG_BT from the used stack makes more sense. -- 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]
