RFC - handling kvargs options without value

RFC - handling kvargs options without value

[Stephen Hemminger]

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.