From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6B6982C2F; Tue, 28 Mar 2017 17:24:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490714667; x=1522250667; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=L37K2obNK9J4PM2/s2UKDV0y/rgUtAEI06tUfO7ymgg=; b=H9kLLALcU4xmP5iqU7FqXQoFLTcaxb5ff5/wCnD2p4b4E1UM5Cbvqdf4 SSN45zR7g0JOf/jNbKgkxqGzWrkqKw==; Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 08:24:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,236,1486454400"; d="scan'208";a="66024255" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.140]) by orsmga002.jf.intel.com with SMTP; 28 Mar 2017 08:24:23 -0700 Received: by (sSMTP sendmail emulation); Tue, 28 Mar 2017 16:24:22 +0100 Date: Tue, 28 Mar 2017 16:24:22 +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: <20170328152421.GA22176@bricha3-MOBL3.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <22590962.V8IQgtpKlO@xps13> <3EB4FA525960D640B5BDFFD6A3D891265277FF85@IRSMSX108.ger.corp.intel.com> <82821129.A9hgLN2u53@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82821129.A9hgLN2u53@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:24:27 -0000 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. In short, I'd like to see this used more, rather than dropped. I think we need a common config lib in DPDK. If not this, we need an external mandatory dependency, and I'd prefer to stick with what we have for now. At minimum, I think any removal of this is premature. Regards, /Bruce