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

[Bruce Richardson]

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