acassis commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6367518839
> @acassis
>
> Regarding `CONFIG_BT`, let me explain the rationale:
>
> 1. **Naming consistency**
> zblue is a full port of the Zephyr RTOS Bluetooth host stack. Its
public API follows Zephyr's `bt_` naming conventions exactly (e.g.
`bt_enable()`, `bt_le_adv_start()`, `bt_gatt_service_register()`), and the
Kconfig symbols correspondingly use the Zephyr-style `CONFIG_BT_*` scheme. If
we introduce an intermediate abstraction layer like `CONFIG_WIRELESS_BLUETOOTH`
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.
>
> 2. **Current NuttX Bluetooth Kconfig landscape**
> NuttX currently has the following Bluetooth-related configuration
subsystems:
>
>
> 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
>
> Note that `WIRELESS_BLUETOOTH_HOST` and `NIMBLE` are already mutually
exclusive (NimBLE has `depends on !WIRELESS_BLUETOOTH_HOST`), so the top level
has always been a two-way choice.
>
> 3. **No additional protocol stacks on the horizon**
> The end goal of introducing zblue is to replace the legacy
`WIRELESS_BLUETOOTH` implementation with `CONFIG_BT`. 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 `CONFIG_BT` needs to dispatch
across "multiple Bluetooth stacks" — zblue will be the single in-kernel
Bluetooth host implementation going forward.
>
> 4. **Userspace compatibility**
> I'll make sure that as `CONFIG_BT` replaces the legacy stack,
existing userspace tools (such as `btsak`, `btsnoop`-related IOCTLs, etc.)
remain compatible, avoiding breaking changes for upper-layer applications.
@anchao as I said before the zblue should be an option not the default, the
fact that there nobody worked on BLE on NuttX yet doesn't mean item 3 is true,
as I said I started working on it.
I think it is fine to keep the convection/API used on Zephyr (bt_*), but
CONFIG_BT should be like a CONFIG_NET. And CONFIG_NIBLE, CONFIG_ZBLUE or
CONFIG_WIRELESS_BLUETOOTH (or CONFIG_NXBLE/NXBT/BTBLUE) should be selected as
the stack.
Please use this opportunity to make the BLUETOOTH selection on NuttX more
simple and intuitive. Assuming ZBLUE as the default and many option is not
safe, some people will prefer other option (as @raiden00pl commented)
--
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]
