Re: [dpdk-dev] [RFC] New CLI for DPDK

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2017-03-28 13:19, Wiles, Keith:
> > On Mar 28, 2017, at 5:06 AM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > 2017-03-24 14:48, Wiles, Keith:
> >> True CLI is not the heart of DPDK, but adding a better supported CLI could be a reasonable addition to DPDK for developers to create a real produce instead of cmdline, which is stated was not a CLI for a real product.
> > 
> > We can ask to the techboard whether CLI is in DPDK scope.
> > My position: it is neither in the scope of the repo nor in the scope of dpdk.org.
> 
> The goal is to replace the cmdline with CLI or at least provide a much better supported and easier solution for DPDK developers.
> 
> The CLI was written just for DPDK and uses DPDK APIs only, so to me it is related to DPDK like any other tool or library we have in DPDK that is not really providing packet transport. We have a number of these in DPDK today and having a library repo on DPDK.org is the very reasonable.
> 
> Also I thought we decided to add the repo to DPDK.org and the only reason we are revisiting if CLI should be on DPDK.org is how we support external libs of this type.
> 
> Thomas started out not liking the name of librte_cli and wanted some other name. I suggested ‘cli’, but I wanted to keep the librte_cli name as I wanted to be able to pull the librte_cli into the DPDK/lib directory to make it simpler to integrate into DPDK for the developer. Building library or applications external to DPDK has a few issues and not completely supported well in DPDK.
> 
> I would like to clone DPDK then clone librte_cli into the DPDK/lib directory allowing librte_cli to be built as a internal library. Then add the config option to the common_base and DPDK/lib/Makefile to allow the library to be built. This allow the developer to find the include and library easily, which then allows us to start looking at updating the current apps to use CLI.
> 
> I could provide a patch to DPDK to help integrate CLI into DPDK without modifying DPDK today for the developer to be able to use CLI as a standard internal library. My goal is to provide a cleaner solution for DPDK developers and a DPDK support CLI.
> 
> I am now a bit confused as to why Thomas has objected here and requested to be push to the TechBoard.

I am sorry, I have realized in the discussion that it is not my call anymore
to decide which repo can be added on dpdk.org.
I have to apply a Technical Board decision which must comply with the (upcoming)
Governing Board directives.