Re: [dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.