2017-03-28 10:22, Bruce Richardson: > On Tue, Mar 28, 2017 at 10:18:28AM +0100, Bruce Richardson wrote: > > On Tue, Mar 28, 2017 at 10:29:44AM +0200, Thomas Monjalon wrote: > > > 2017-03-09 08:10, Allain Legacy: > > > > This patchset includes some minor enhancements that we have developped > > > > for > > > > our DPDK application. We would like to contribute them upstream to help > > > > ease adoption of the DPDK by anyone looking for this type of > > > > functionality. The commit logs on each patch should be self-sufficient > > > > in > > > > explaining the intent and purpose. > > > > > > This series is small enough to be merged. > > > However, in the long term, we should not have this kind of library in > > > DPDK. > > > > > > librte_cfgfile is used by the examples ip_pipeline and qos_sched. > > > I think the purpose of an example is to show some simple code > > > demonstrating > > > a feature. > > > Examples using a configuration file are closer to a complete application. > > > > > > Anyway, why not use an external library like this one? > > > https://github.com/vstakhov/libucl > > > > Because as a general rule, anything adding in external dependencies needs > > to be disabled by default. This leads to the catch-22 situation I > > flagged before, and had no follow-up on. There is no way right now for > > someone to put in extra functionality like this into DPDK and have it > > default enabled. If you try putting it into DPDK directly, it will be > > rejected as duplicating other libs, but if you re-use the libs, it will > > be disabled by default as adding in an extra dependency. > > > > /Bruce > > 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. > 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.
