Re: [PATCH v2 0/6] librte_cfgfile enhancements
From: Thomas Monjalon <hidden>
Date: 2017-03-28 15:41:03
2017-03-28 16:24, Bruce Richardson:
On Tue, Mar 28, 2017 at 12:12:26PM +0200, Thomas Monjalon wrote:quoted
2017-03-28 09:58, Dumitrescu, Cristian:quoted
quoted
quoted
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.