acassis commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6414726567
> @acassis > > I think there are 3 technical details worth considering again. > > First, in ESP-IDF, Bluedroid and NimBLE are mutually exclusive host stack choices. That means users who need Classic Bluetooth have to select Bluedroid, and then they cannot use NimBLE at the same time for BLE-only features. This also means that features such as LE Mesh or LE Audio cannot naturally be combined with the Classic Bluetooth stack if they are only available from a different host stack. > > https://github.com/espressif/esp-idf/blob/d35ea023029363d97c42565f85e0db23486f26b2/components/bt/Kconfig#L9-L33 > > This is one important difference from the ZBlue direction. ZBlue provides a single host stack architecture that can cover Classic, BLE, Mesh, LE Audio, and other Bluetooth features under one Bluetooth host implementation. So from a long-term architecture point of view, I think it is not exactly the same problem as choosing between Bluedroid and NimBLE in ESP-IDF. > > Second, regarding the Kconfig naming, if we use ESP-IDF as a reference, I think we should also notice that its naming is not strictly stack-prefixed everywhere. For example, once Bluedroid is selected, many Classic/BLE feature options still use generic `CONFIG_BT_*` names, such as: > > ``` > CONFIG_BT_CLASSIC_ENABLED > CONFIG_BT_A2DP_ENABLE > CONFIG_BT_AVRCP_ENABLED > CONFIG_BT_SPP_ENABLED > CONFIG_BT_L2CAP_ENABLED > CONFIG_BT_BLE_ENABLED > CONFIG_BT_GATTS_ENABLE > CONFIG_BT_GATTC_ENABLE > ``` > > https://github.com/espressif/esp-idf/blob/d35ea023029363d97c42565f85e0db23486f26b2/components/bt/host/bluedroid/Kconfig.in#L105 > > So even ESP-IDF does not consistently use `CONFIG_BT_BLUEDROID_*` for all Bluedroid features. The stack name is mainly used for selecting the host stack, while many actual Bluetooth feature options remain under generic `CONFIG_BT_*`. > > That is why I still think exposing ZBlue in every Bluetooth feature Kconfig name is not necessarily the right direction. It makes the configuration look more implementation-specific than the feature itself, and I think this will be harder for Bluetooth developers to understand and maintain in the long term. > > Third, this naming inconsistency is even more visible in the Bluetooth controller part. ESP-IDF's BLE controller feature set is actually very similar to Zephyr's Bluetooth controller in terms of BLE 5 features, extended advertising, periodic advertising/sync, 2M PHY, and coded PHY support. However, unlike Zephyr, which uses a consistent and unified `CONFIG_BT_CTLR_*` prefix for Bluetooth controller options, ESP-IDF does not follow a single naming convention here. For example, it mixes multiple naming styles in the same Bluetooth subsystem: > > ``` > CONFIG_BT_CONTROLLER_* > CONFIG_BTDM_CTRL_* > CONFIG_BT_CTRL_* > CONFIG_BT_LE_* > ``` > > Some examples are: > > ``` > CONFIG_BT_CTRL_BLE_MAX_ACT > CONFIG_BT_CTRL_ADV_DUP_FILT_MAX > CONFIG_BT_LE_50_FEATURE_SUPPORT > CONFIG_BT_LE_LL_CFG_FEAT_LE_2M_PHY > CONFIG_BT_LE_LL_CFG_FEAT_LE_CODED_PHY > CONFIG_BT_LE_EXT_ADV > CONFIG_BT_LE_ENABLE_PERIODIC_ADV > CONFIG_BT_LE_ENABLE_PERIODIC_SYNC > ``` > > In Zephyr, similar controller capabilities are organized under one coherent controller namespace, for example: > > ``` > CONFIG_BT_CTLR_PHY_2M > CONFIG_BT_CTLR_PHY_CODED > CONFIG_BT_CTLR_ADV_EXT > CONFIG_BT_CTLR_ADV_PERIODIC > CONFIG_BT_CTLR_SYNC_PERIODIC > ``` > > So if ESP-IDF is used as the reference model, I think we should also recognize that its Bluetooth configuration is not a clean, unified design. It looks more like several historical parts stitched together with different naming conventions. Is this kind of fragmented Bluetooth organization really the direction we want to carry forward in NuttX, instead of keeping a coherent Bluetooth configuration model? @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. -- 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]
