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.bou...@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).
