Hi Keith, I'll try to bring more context to this discussion below.
2016-06-01 15:00, Wiles, Keith: > Started from the link below, but did not want to highjack the thread. > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > I was thinking about this problem from a user perspective and command > line options are very difficult to manage specifically when you have > a large number of options as we have in dpdk. The user uses an application. It is up to the application to let users do some configuration. > I see all of these options as a type of database of information for > the DPDK and the application, because the application command line > options are also getting very complex as well. DPDK is a collection of libraries. There is no command line options in a library. So we should not be talking about such issue. But... ... configuration of the DPDK libraries must be improved. We need some clean API to let the application configure a lot of things at runtime (during initialization or after). Ideally the API should not use an argc/argv format. We also have a lot of applications for tests or examples which use a common configuration scheme based on command line options. It is only for test and demonstration purpose. So it is not so important and must not be complex to maintain. I also think that we should avoid having to modify a configuration file for test applications. I like launching a freshly built testpmd with a copy-pasted command line without having to create a temporary configuration file. Instead of wrapping a messy configuration interface, we should proceed with this steps (in this order): - implement clean configuration API - move command line options parsing in a separate library - implement an alternative to the options parsing library, as an example - remove the options parsing library if the alternative is better
