[PATCH v4 0/8] add new command line argument parsing library

[Thomas Monjalon]

18/12/2023 10:18, Bruce Richardson:
> On Fri, Dec 15, 2023 at 01:53:21PM -0800, Stephen Hemminger wrote:
> > On Fri, 15 Dec 2023 17:26:24 +0000
> > Euan Bourke <euan.bourke at intel.com> wrote:
> > 
> > > A recent thread on the mailing list[1] discussed corelist and coremask
> > > parsing and the idea of a new library dedicated to command line parsing
> > > was mentioned[2]. This patchset adds the library, along with the new
> > > APIs, and edits the existing EAL, DLB2 driver and some example
> > > application functions to use these APIs, rather than each implementing
> > > their own copies.
> > > 
> > > The new APIs work similar to the existing functions in EAL, however
> > > instead of filling a core array like this:
> > > [1, -1, -1, 2, 3] (a non -1 refers to an 'active core' at that index)
> > > It fills it like this:
> > > [0, 3, 4] (with the value at each index being an 'active core').
> > > 
> > > The new APIs will also return the number of cores contained in the
> > > passed corelist/coremask, so in the above example, 3 would be returned.
> > > 
> > > Also included in this patchest is a heuristic parser which searches
> > > for key markers in the core string, returning a enum value based off
> > > this search to indicate if a parameter is likely a coremask or a
> > > corelist. This heuristic function is also wrapped in a parser
> > > function allowing apps to handle both coremasks and corelists
> > > simultaneously.
> > > 
> > > [1] https://mails.dpdk.org/archives/dev/2023-November/280957.html
> > > [2] https://mails.dpdk.org/archives/dev/2023-November/280966.html
> > > 
> > 
> > The code is ok, but the naming needs to change.
> > 
> > To me the name argparse implies that library implements something
> > similar to Python argparse. But that isn't what this library does.
> > It seems limited to just cpu masks. Perhaps cpuparse would be better name
> > or make it part of a larger implementation of a full library
> > more like Python argparse.
> 
> Yes, it is a limited set of functions, so the name is probably not ideal if
> that's what it's going to remaini (though what library ever stays
> un-expanded once started!).

This is a string parsing library.

> I think we need a general discussion
> on-list and probably in tech-board too about argument handling, since in
> the last couple of months there have been no less than 3 separate
> independent proposals around functionality for arguments.
> 
> There has been:
> * This set, for extracting out functions for processing coremask and
>   corelist arguments. Presumably other argument parsing types may look to
>   be included in future e.g. device args, perhaps.
> * A set from me [1], looking to take the slightly opposite side of things, and 
>   make it easier for apps to initialize EAL with a custom argument set. So
>   it can be thought of as an argument-list management library.
> * An "argparse" library from Chengwen [2] which does what you describe
>   above and be a C implementation like the python argparse module.
> 
> We need to decide how to manage all these three, if we want to take them
> all, and if they should all be merged into a single library, or some kept
> separate from others.

Yes, we need to decide whether we want to keep this string parsing
as a standalone library, or we prefer to integrate it in Chengwen's
global argument parsing library.

The question is do we want to do string parsing out of the global argument parsing?
I suppose the answer is yes, at least when parsing devargs in drivers.
In this case we need this library to be standalone (and reused in Chengwen's argparse).