2017-03-28 13:19, Wiles, Keith: > > On Mar 28, 2017, at 5:06 AM, Thomas Monjalon <thomas.monja...@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.
