From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 9D6A628F3; Tue, 28 Mar 2017 17:42:41 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 28 Mar 2017 08:42:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,237,1486454400"; d="scan'208";a="949055899" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.140]) by orsmga003.jf.intel.com with SMTP; 28 Mar 2017 08:42:38 -0700 Received: by (sSMTP sendmail emulation); Tue, 28 Mar 2017 16:42:37 +0100 Date: Tue, 28 Mar 2017 16:42:37 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: "Dumitrescu, Cristian" , "Legacy, Allain (Wind River)" , dev@dpdk.org, "yuanhan.liu@linux.intel.com" , techboard@dpdk.org Message-ID: <20170328154237.GA24244@bricha3-MOBL3.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <82821129.A9hgLN2u53@xps13> <20170328152421.GA22176@bricha3-MOBL3.ger.corp.intel.com> <13936610.WgrjQNdGoS@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13936610.WgrjQNdGoS@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.0 (2017-02-23) Subject: Re: [dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:42:42 -0000 On Tue, Mar 28, 2017 at 05:41:01PM +0200, Thomas Monjalon wrote: > 2017-03-28 16:24, Bruce Richardson: > > On Tue, Mar 28, 2017 at 12:12:26PM +0200, Thomas Monjalon wrote: > > > 2017-03-28 09:58, Dumitrescu, Cristian: > > > > > > As follow-up to my own mail, for this specific library example, I > > > > > > wouldn't look to remove it from DPDK anyway. Parsing ini files is fairly > > > > > > trivial, so I think it's not a big deal to keep our own version and not > > > > > > have an external dependency - especially since it's already there and not > > > > > > a big maintenance burden. > > > > > > > > > > Removing this lib would not disable anything as it is used only by examples. > > > > > I don't see what would be the issue. > > > > > We just have to download the lib when building the example app. > > > > > It can be done quite easily in the makefile. > > > > > > > > Thomas, more than 3 quarters of DPDK libs are only used by applications, is this a reason to remove them? > > > > > > > > Also, I think the purpose of DPDK is to enable people to write applications, not more libraries. Would you agree? We should make the life easier for the application developers, not libraries. > > > > > > > > This library is an important utility for applications, similar to librte_cmdline and others. I think it is not fair from your side to refer to librte_cfgfile without any reference to librte_cmdline. > > > > > > I agree Cristian. > > > I was just writing another email about removing librte_cmdline: > > > http://dpdk.org/ml/archives/dev/2017-March/061777.html > > > This thread was about librte_cfgfile. I hope you'll agree I am really fair :) > > > > > > It is really a scope question and should be managed by the techboard (CC). > > > > > Sure. > > > > As for my 2c right now on this lib, I'm very much in favour of keeping > > it. I also think we should look to reuse it as an alternative way of > > passing parameters to EAL. The existing method of using argc/argv makes > > passing a lot of args, e.g for devices clunky, and re-using code from > > cfgfile library gives us an alternative without adding extra > > dependencies. I also think it could be useful for testpmd, which is > > similarly "blessed" with lots of cmdline args to pass. > > I think we must improve the API and later deprecate argc/argv. > The configuration must be done by the application. > It should be the application choice to get its input from the command line, > a CLI or a config file. > Yes, that's exactly what I was thinking. /Bruce