From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 0/6] librte_cfgfile enhancements Date: Tue, 28 Mar 2017 12:12:26 +0200 Message-ID: <82821129.A9hgLN2u53@xps13> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <22590962.V8IQgtpKlO@xps13> <3EB4FA525960D640B5BDFFD6A3D891265277FF85@IRSMSX108.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Richardson, Bruce" , "Legacy, Allain (Wind River)" , dev@dpdk.org, "yuanhan.liu@linux.intel.com" , techboard@dpdk.org To: "Dumitrescu, Cristian" Return-path: Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by dpdk.org (Postfix) with ESMTP id 0A278D003 for ; Tue, 28 Mar 2017 12:12:27 +0200 (CEST) Received: by mail-wr0-f175.google.com with SMTP id u1so96940082wra.2 for ; Tue, 28 Mar 2017 03:12:27 -0700 (PDT) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265277FF85@IRSMSX108.ger.corp.intel.com> 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 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). > > > For newer functionalty, we do need clear guidelines as to when it is > > > acceptable to add new dependencies to DPDK. I'd love to see us enable > > > the PCAP PMD by default, for instance, and I think Sergio has recently > > > proposed we also require libnuma on Linux. > > > > We won't include libpcap or libnuma. > > The only thing we should do is to make easier to view and enable > > dependencies.