anchao commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6366983719
<html><head></head><body><p>@acassis</p> <p>Regarding <code>CONFIG_BT</code>, let me explain the rationale:</p> <ol style="list-style-type: decimal;"> <li><strong>Naming consistency</strong> zblue is a full port of the Zephyr RTOS Bluetooth host stack. Its public API follows Zephyr's <code>bt_</code> naming conventions exactly (e.g. <code>bt_enable()</code>, <code>bt_le_adv_start()</code>, <code>bt_gatt_service_register()</code>), and the Kconfig symbols correspondingly use the Zephyr-style <code>CONFIG_BT_*</code> scheme. If we introduce an intermediate abstraction layer like <code>CONFIG_WIRELESS_BLUETOOTH</code> in Kconfig but leave the API layer unchanged, it creates an inconsistency — users would see one naming convention in Kconfig and a completely different one when writing code. Since the API is already locked to Zephyr compatibility, keeping Kconfig consistent with it is the right design choice.</li> <li><strong>Current NuttX Bluetooth Kconfig landscape</strong> NuttX currently has the following Bluetooth-related configuration subsystems:</li> </ol> Subsystem | Top-level Kconfig | Location -- | -- | -- Legacy BLE stack (Intel/Zephyr arduino101 port) | WIRELESS_BLUETOOTH / WIRELESS_BLUETOOTH_HOST | wireless/bluetooth/Kconfig NimBLE (Apache Mynewt port) | NIMBLE | nuttx-apps wireless/bluetooth/nimble/Kconfig HCI driver layer | DRIVERS_BLUETOOTH | drivers/wireless/bluetooth/Kconfig Bluetooth socket (based on legacy stack) | NET_BLUETOOTH | net/bluetooth/Kconfig New Zephyr Bluetooth host stack (zblue) | BT | libs/zblue/Kconfig <p>Note that <code>WIRELESS_BLUETOOTH_HOST</code> and <code>NIMBLE</code> are already mutually exclusive (NimBLE has <code>depends on !WIRELESS_BLUETOOTH_HOST</code>), so the top level has always been a two-way choice.</p> <ol start="3" style="list-style-type: decimal;"> <li><strong>No additional protocol stacks on the horizon</strong> The end goal of introducing zblue is to replace the legacy <code>WIRELESS_BLUETOOTH</code> implementation with <code>CONFIG_BT</code>. zblue is far more feature-complete than the legacy stack (LE Audio, Mesh, BR/EDR Classic, etc.). So there won't be a scenario where a generic <code>CONFIG_BT</code> needs to dispatch across "multiple Bluetooth stacks" — zblue will be the single in-kernel Bluetooth host implementation going forward.</li> <li><strong>Userspace compatibility</strong> I'll make sure that as <code>CONFIG_BT</code> replaces the legacy stack, existing userspace tools (such as <code>btsak</code>, <code>btsnoop</code>-related IOCTLs, etc.) remain compatible, avoiding breaking changes for upper-layer applications.</li> </ol> -- 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]
