acassis commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384895827
> > @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. > > @acassis > > Yes, I understand your point, and I agree that NuttX Kconfig does not have to be 1:1 with Linux or Zephyr. > > At this stage, many of the Bluetooth Kconfig options are inherited from Zephyr, because the stack is derived from Zephyr. However, after this point, I do not expect us to keep synchronizing the Kconfig directly with Zephyr. We have already made many NuttX-specific integration changes, and it will become increasingly difficult to keep this as a clean downstream sync. > > So my view is that this is more like forking the current Bluetooth host stack into NuttX and maintaining it as the NuttX Bluetooth implementation from now on, rather than keeping it as a stack that is always selected as "Zephyr Bluetooth" inside NuttX. > > The main reason I would still like to keep the CONFIG_BT_* naming is that the core Bluetooth configuration model is already familiar to developers who have used Linux or Zephyr Bluetooth before. It also describes the Bluetooth features themselves, not only the implementation identity. For example, options like CONFIG_BT_CONN, CONFIG_BT_HCI, CONFIG_BT_L2CAP, CONFIG_BT_GATT, etc. are natural Bluetooth feature names. > > If CONFIG_BT is merged as the common Bluetooth host entry in NuttX, my expectation is that it will become the main NuttX Bluetooth implementation going forward. Similar to the TCP/IP stack in NuttX, I think the community should focus on maintaining and improving one in-tree implementation instead of carrying multiple host stacks long-term. > > For NimBLE, if there are active users or maintainers who still need it, we can discuss that with them. But if there is no strong user requirement for keeping a separate NimBLE path, I think it would be better to encourage users to move to the NuttX-maintained ZBlue-based Bluetooth stack once it provides the required BLE functionality. > > So I agree with the idea that CONFIG_BT should mean Bluetooth support in NuttX. The difference is that I do not see ZBlue as a temporary third-party stack once it is merged and maintained in-tree. I see it as the basis of the future NuttX Bluetooth host implementation. @anchao I think that is our main point of divergence: I think ZBlue should be an option to allow others BT/BLE stack be used in the future, you think that ZBlue should become the NuttX default BT/BLE stack. If you use CONFIG_BT_ZBLUE_HCI/L2CAP/GATT, etc, everybody will understand that it means, but selecting CONFIG_BT_HCI/etc to ZBLUE means we are giving it higher privilege (I think NimBLE and other should have the same opportunity to evolve). NimBLE for instance is actively maintained and was certified on Espressif chips: https://www.espressif.com/en/news/BLE_5.0_Certification So, I my point is: I am fine to let ZBlue in, but I'm not fine to let it to became the standard/official NuttX BT/BLE stack. -- 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]
