24/01/2024 14:33, 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.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).
The argparse library is now merged, so we can followup with string parsing proposed in this series.
