Allow vendor extension to the CLI App?

[Irving-cl]

Goal and Background
The goal is to make it easier for vendors to build a test app with additional functions of their own based on the CLI app.

• Sometimes only a small additional function is needed, it's not worthwhile to write a new test app from scratch which takes much more time.
• While vendors can directly modify the code in CLI library in their internal forks, that makes it more difficult to sync the code(may need to regularly resolve conflicts when there is an update in CLI).

Describe the solution you'd like
Similar as what we did to support extension in NCP. Will make these changes:

1. Add a CmdEntry("ext") in the list kCommands in the Cli module. The entry will be guarded by a switch OPENTHREAD_CONFIG_CLI_EXTENSION.
2. Add two new sources in the cli directory: cli_ext.hpp and cli_ext.cpp. Similar as other cli modules, there will be a new class CliExtension which inherits Output. Implement the Process method with a dummy implementation. The two files should keep unchanged in OT. Vendors can change it in their internal code.
3. Add a new CMake switch to control the Cli extension. Add the two sources when the switch is on.
4. May consider adding a new variable just like OT_NCP_VENDOR_HOOK_SOURCE for ncp in CMake to allow vendors to add more source files. That won't be a big problem.

Why not using otCliSetUserCommands for vendors to add extensions?

• otCliSetUserCommands is used in the main.c of cli app and posix app. So an extension is required in both apps, then we need to add some code twice, also for the changes in build files.
• Since otCliSetUserCommands is already used in cli app and posix app, it's hard to make it extendable because kCommands has been defined.

Thoughs? @abtink @jwhui

[bertoldi-silabs]

Hello, I'm chiming in as I am in the process of planning similar work. I appreciate the description of your solution, and I think that there is merit to consider it, but I will also mention my thoughts on the topic before this proposal.

I have been considering the otCliSetUserCommands direction that you outline. There is a pull request to update otCliSetUserCommands to be able to append a command list after one is already set. As you point out, this would then involve making similar changes in both the cli and posix apps, but a hook could be added to call otCliSetUserCommands with an externally provided command struct instead of needing to update kCommands. My impression is that this is less work, but it is a rather indirect way of adding support for vendor commands.

I appreciate that this is a more explicitly direct method of showcasing that vendor cli commands are supported, and I appreciate that the implementation description matches other standard references in the codebase. The one point that is outwardly different from the approach that I'm considering so far, is the CmdEntry("ext"). It is unclear to me whether or not it would be a beneficial change to have registered vendor commands specifically identified as "ext" commands or if it would even be unnecessary, as opposed to registering the commands directly as the apps handle the user commands.

Thank you for starting this discussion. Supporting vendor cli commands is a topic that is very relevant to my use case at the moment, and I would be very interested in seeing additional perspectives and engagement.

[Irving-cl]

@bertoldi-silabs Thanks! With the PR I think it's good to use otCliSetUserCommands.

but a hook could be added to call otCliSetUserCommands with an externally provided command struct instead of needing to update kCommands

Do you mean something like:

• Add calling of otCliSetUserCommands in both main.c for cli and posix and provide a extern command list
• The actual command list is in vendor's source file

[bertoldi-silabs]

Yes, that is pretty much right along the lines of my initial thoughts.

My objective was to be able to define one command list in an external vendor source file which can be used for both cli and posix. In order to actually use that, I think it would be as you describe in terms of adding the otCliSetUserCommands to both main.c files, possibly guarded by a configuration switch.

[Irving-cl]

Sounds good to me :)

[jwhui]

Resolved by #8977