Add OpenThread Spinel HDLC RCP host interface files to Zehyr

[dleach02]

Origin

OpenThread Project

https://github.com/openthread/openthread/tree/main/src/posix/platform

Purpose

Adds Zephyr support for OpenThread HDLC/Spinel RCP communications.

Mode of integration

Add relevant files to modules/openthread/platform interface directory in Zephyr repository.

• hdlc_interface.cpp
• hdlc_interface.hpp
• radio_spinel.cpp

Maintainership

Covered by OpenThread maintainer list

Pull Request

#75986

Description

Adds support for RCP design where the core of OpenThread lives in a connected RCP radio controller over a HDLC interface.

Dependencies

None

Revision

Copying the posix version of the files from OpenThread and making relevant changes to support Zephyr integration.

License

BSD-3-Clause

[dleach02]

ping @rlubos @JA-NXP

[nashif]

beside the license, those files being pulled are c++!

[dleach02]

beside the license, those files being pulled are c++!

Yes. OpenThread module is also all c++ so makes sense that these files would be as well. I'll let the networking WG discuss why but it was observed that this isn't the first instance of doing this within Zephyr:

• zephyr\modules\thrift\src\thrift\transport\TSSLSocket.cpp
• zephyr\modules\thrift\src\thrift\server\TServerFramework.cpp

The initial question about the license is what this RFC wants to resolve/discuss with TSC

[dleach02]

From the TSC meeting notes, 3 questions:

• License? Not an issue
• Moving things from module into the tree: Why do we need to do this and what would the maintenance model be?
  @rlubos @xavraz @JA-NXP please provide some clarity on this question here.
• C++ [@nashif can you articulate the concern here?]

[rlubos]

Regarding C++ use, the reason for this is that the communication protocol between Host and RCP (Spinel) does not expose C interface, therefore the host-side implementation for this needs to inherit from ot::Spinel::SpinelInterface and for this we need to use C++ for that particular functionality. I don't really see a way around this, but I personally, as a OT maintainer, I don't have a problem with that.

[JA-NXP]

I agree with @rlubos regarding the C++ explanation. Indeed, Spinel layer is coded in C++ by Openthread and does not expose C interface to use it. Therefore, C++ code is used for the communication over Spinel between host and radio device for an RCP architecture.
There is also the same discussion in the PR before. You can refer to it here: #75986 (comment)

[nashif]

• C++ [@nashif can you articulate the concern here?]

The concern here is that we have a general rule of not including C++ code in the tree. Now this can be dealt with as an exception and with the right reasoning as provided above, i.e. this is needed to support a module which is already c++.

"we have other C++ code already." is not a valid reason.

So it is fine to accept this as an exception given the context, and this should not indicate that adding c++ in the future, for example for a new subsystem should be justified by pointing that we now have 2 areas that already have c++ files.