anchao commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384719984
> @anchao but NuttX Kconfig is not 1:1 to Linux or Zephyr (it shouldn't be).
So I think CONFIG_BT should mean BT/BLE supoort and then we have the stack
used: CONFIG_BT_NIMBLE, CONFIG_BT_ZBLUE, etc.
>
> Does it makes more sense? If we used CONFIG_BT to compile the ZBLUE stack
only, it will be difficult to repurpose it to other stack later. So I think
separating CONFIG_BT from the used stack makes more sense.
@acassis
Yes, I understand your point, and I agree that NuttX Kconfig does not have
to be
1:1 with Linux or Zephyr.
At this stage, many of the Bluetooth Kconfig options are inherited from
Zephyr,
because the stack is derived from Zephyr. However, after this point, I do
not
expect us to keep synchronizing the Kconfig directly with Zephyr. We have
already
made many NuttX-specific integration changes, and it will become
increasingly
difficult to keep this as a clean downstream sync.
So my view is that this is more like forking the current Bluetooth host
stack
into NuttX and maintaining it as the NuttX Bluetooth implementation from now
on,
rather than keeping it as a stack that is always selected as "Zephyr
Bluetooth"
inside NuttX.
The main reason I would still like to keep the CONFIG_BT_* naming is that
the
core Bluetooth configuration model is already familiar to developers who
have
used Linux or Zephyr Bluetooth before. It also describes the Bluetooth
features
themselves, not only the implementation identity. For example, options like
CONFIG_BT_CONN, CONFIG_BT_HCI, CONFIG_BT_L2CAP, CONFIG_BT_GATT, etc. are
natural
Bluetooth feature names.
If CONFIG_BT is merged as the common Bluetooth host entry in NuttX, my
expectation is that it will become the main NuttX Bluetooth implementation
going
forward. Similar to the TCP/IP stack in NuttX, I think the community should
focus on maintaining and improving one in-tree implementation instead of
carrying
multiple host stacks long-term.
For NimBLE, if there are active users or maintainers who still need it, we
can
discuss that with them. But if there is no strong user requirement for
keeping a
separate NimBLE path, I think it would be better to encourage users to move
to
the NuttX-maintained ZBlue-based Bluetooth stack once it provides the
required
BLE functionality.
So I agree with the idea that CONFIG_BT should mean Bluetooth support in
NuttX.
The difference is that I do not see ZBlue as a temporary third-party stack
once
it is merged and maintained in-tree. I see it as the basis of the future
NuttX
Bluetooth host implementation.
--
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]
