From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC] New CLI for DPDK Date: Tue, 28 Mar 2017 15:30:30 +0200 Message-ID: <2035625.W01lfWd7dv@xps13> References: <1976507.q6Vb44MXhO@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Olivier Matz , techboard@dpdk.org To: "Wiles, Keith" Return-path: Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) by dpdk.org (Postfix) with ESMTP id 3490FCFEC for ; Tue, 28 Mar 2017 15:30:32 +0200 (CEST) Received: by mail-lf0-f53.google.com with SMTP id x137so38143360lff.3 for ; Tue, 28 Mar 2017 06:30:32 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-03-28 13:19, Wiles, Keith: > > On Mar 28, 2017, at 5:06 AM, Thomas Monjalon wrote: > > 2017-03-24 14:48, Wiles, Keith: > >> True CLI is not the heart of DPDK, but adding a better supported C= LI could be a reasonable addition to DPDK for developers to create a re= al produce instead of cmdline, which is stated was not a CLI for a real= product. > >=20 > > 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 scop= e of dpdk.org. >=20 > The goal is to replace the cmdline with CLI or at least provide a muc= h better supported and easier solution for DPDK developers. >=20 > The CLI was written just for DPDK and uses DPDK APIs only, so to me i= t is related to DPDK like any other tool or library we have in DPDK tha= t is not really providing packet transport. We have a number of these i= n DPDK today and having a library repo on DPDK.org is the very reasonab= le. >=20 > Also I thought we decided to add the repo to DPDK.org and the only re= ason we are revisiting if CLI should be on DPDK.org is how we support e= xternal libs of this type. >=20 > Thomas started out not liking the name of librte_cli and wanted some = other name. I suggested =E2=80=98cli=E2=80=99, 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 d= eveloper. Building library or applications external to DPDK has a few i= ssues and not completely supported well in DPDK. >=20 > I would like to clone DPDK then clone librte_cli into the DPDK/lib di= rectory 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 th= e 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. >=20 > I could provide a patch to DPDK to help integrate CLI into DPDK witho= ut modifying DPDK today for the developer to be able to use CLI as a st= andard internal library. My goal is to provide a cleaner solution for D= PDK developers and a DPDK support CLI. >=20 > I am now a bit confused as to why Thomas has objected here and reques= ted to be push to the TechBoard. I am sorry, I have realized in the discussion that it is not my call an= ymore 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.