anchao commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6376074636
<html><head></head><body><p>@acassis</p> <p>I appreciate the detailed feedback, and I understand the concern about not assuming zblue as the sole option. Let me share my perspective on why I think keeping <code>CONFIG_BT</code> as-is is actually the simpler and more intuitive path here.</p> <ol style="list-style-type: decimal;"> <li><strong>zblue is not BLE-only — it's a full Bluetooth stack</strong> This isn't just another BLE host. zblue covers Classic Bluetooth (BR/EDR with A2DP, AVRCP, HFP, HID, etc.), Bluetooth Mesh, and LE Audio (BAP, CAP, TMAP, PBP, and a dozen more profiles). The legacy <code>WIRELESS_BLUETOOTH</code> stack and NimBLE are both BLE-only by comparison. From a functionality standpoint, zblue is the most comprehensive Bluetooth implementation in NuttX, and it makes sense for its Kconfig to reflect that scope rather than being pigeonholed as "one of several BLE options."</li> <li><strong>No naming conflict exists today</strong><code>CONFIG_BT</code> doesn't collide with any existing NuttX Kconfig symbol. The current stacks already have their own distinct top-level names:</li> </ol> Stack | Top-level config | Scope -- | -- | -- Legacy NuttX BLE | WIRELESS_BLUETOOTH | BLE only NimBLE | NIMBLE | BLE only zblue | BT | LE + Classic + Mesh + LE Audio <p>There's no ambiguity for users — each stack has a clearly identifiable entry point. Adding a <code>CONFIG_BT</code> umbrella on top would actually increase complexity by introducing an extra level of indirection for a problem that doesn't exist yet.</p> <ol start="3" style="list-style-type: decimal;"> <li><strong>Familiarity for developers coming from Linux/Zephyr</strong> One of the explicit goals of this port is to lower the barrier for developers already familiar with the Zephyr Bluetooth ecosystem. A developer who has written <code>prj.conf</code> with <code>CONFIG_BT=y</code> / <code>CONFIG_BT_PERIPHERAL=y</code> in Zephyr will immediately recognize the same configuration scheme in NuttX. This isn't a theoretical benefit — it means existing Zephyr Bluetooth documentation, knowledge, and patterns transfer directly. Renaming to something NuttX-specific (e.g. <code>CONFIG_ZBLUE</code>) would sacrifice that familiarity for no practical gain.</li> <li><strong>The CONFIG_NET analogy is worth reconsidering</strong> I don't think <code>CONFIG_BT</code> maps cleanly to the <code>CONFIG_NET</code> pattern. <code>CONFIG_NET</code> is a genuine umbrella because multiple networking stacks were never the plan — it's a single subsystem with optional features layered underneath. The Bluetooth situation is actually similar: we have legacy stacks that predate this work, and zblue is designed to eventually supersede them, not coexist indefinitely alongside them. Adding a choice menu now to choose between stacks that have different feature sets, different APIs, and different maturity levels doesn't simplify things for users — it forces them to understand the tradeoffs between three implementations before they can even get started.</li> <li><strong>Premature abstraction</strong> If, at some future point, someone contributes another full-featured Bluetooth host stack that uses the same <code>bt_*</code> API surface and genuinely needs to coexist under a shared Kconfig umbrella, that would be the right time to introduce a choice menu. Doing it now, when there's only one stack using this API namespace, is solving a hypothetical problem. The existing stacks (<code>WIRELESS_BLUETOOTH</code>, <code>NIMBLE</code>) each have their own API surface and their own Kconfig entry — they don't need to live under <code>CONFIG_BT</code>.</li> <li><strong>Practical counter-proposal</strong> How about this: we keep <code>CONFIG_BT</code> as the entry point for the Zephyr-derived host stack for now. If another Bluetooth host stack emerges that shares the same <code>bt_*</code> API conventions and genuinely needs to be selectable under a common Kconfig namespace, I'll be the first to help refactor <code>CONFIG_BT</code> into a choice menu at that point. But I'd rather not add an abstraction layer today that serves no immediate purpose and makes the configuration less recognizable for the developers most likely to use this feature.</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]
