anchao commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6407547354
@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](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](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? -- 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]
