There is a problem in current devargs/kvargs code for cases where the device
argument expects a value but none is given. There are a several possible ways
to address the problem and would like some feedback before finalizing a fix.
Options:
0 - do nothing, if no option is given but device expects one then the
driver will crash dereferencing NULL. Not best user experience but
if argument is needed, any error handling only just going to print
error anyway.
1 - fix all the drivers. There is a patch series in patchwork already
that does most of this.
Downside is that it is largish patchset and not sure if everything
is covered and may break with new drivers.
2 - enforce that value must be present in kvargs.
Change the places where driver is not expecting a value now, to instead
take 1/0 as true/false. I.e in TUN driver persist flag, make it
so persist is now: persist=1.
Downside is that change is visible to application startup.
3 - variation of #2. Enforce in kvargs, but let driver make exception.
Add special character to the keys for the case of presence option.
I.e in TUN driver persist flag, set "persist:" and make : be indicator
that no value is expected.
Downside is that it is an API change, that may break applications
using kvargs. But I doubt that any external apps would use this API
anyway.
4. - add new richer api for parsing. Introduce rte_kvargs_getopt()
which takes a structure with three value flag similar to getopt_long
for required_argument, no_argument, optional_argument. Replace all
usage of old API rte_kvargs_parse() , and deprecate it.
This is the most complete change. But requires modifying lots places
that call rte_kvargs_parse().
5. - change rte_kvargs_parse() to take option structure and version the API.
same as #4 but keep the same function name.
Have a start on Option 4. But doing 3 seems easiest.
