From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F1DBB43B3C; Wed, 14 Feb 2024 18:01:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E42D642E97; Wed, 14 Feb 2024 18:01:23 +0100 (CET) Received: from wfout1-smtp.messagingengine.com (wfout1-smtp.messagingengine.com [64.147.123.144]) by mails.dpdk.org (Postfix) with ESMTP id 00BAC42E50 for ; Wed, 14 Feb 2024 18:01:22 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.west.internal (Postfix) with ESMTP id 4F2B01C0005B; Wed, 14 Feb 2024 12:01:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 14 Feb 2024 12:01:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1707930080; x=1708016480; bh=Rqtmd3Yc4sLJLw+qPD0wFQ2VKDFx5aOdaCZbZR+mvT4=; b= mUZiIztovsIjzjSUkqWQKwO77dr5N06jf/dnLDdR3XCRlp7/pdbgkg/RlWhNT88g tk+/Bvf6eEfgCz+J5ocdCuQrow4JBOy4KYyC7RNQPlT6VnLIPuM6OT7XQAhjgves m6OPFsXsbLPpXuQ5mk+RVfjzC8FPzlWBfQdrrO1OG29nrO8kNoy4BQZ/xvswIuYa x/3YNlEBzjVRj3MdWAZ2dIC/cr2z3PEmgYDuD3IrzkNk32ymFZZ7AEOYz2ihskn1 CDMR5XaFuIxH9oWO69aY90e5XRk8OYPDxXZcu5vLVselSbxo9BrCGU/qpqevM2BY L8LmmHFDlfCfstvxoIN+dQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707930080; x= 1708016480; bh=Rqtmd3Yc4sLJLw+qPD0wFQ2VKDFx5aOdaCZbZR+mvT4=; b=p edCjjkJ9KGlPBqA+BshRKEPvl+v6I5MsdZAViNYMEbI3JTNpPzuwLfpRHZS25qpQ ufEpd+nyeIDjYL9wTNIRjwoh9TGYWJZehjMV1CjmidgCmLWNmuU4ErMgMzZFkZFZ 44HeWLRbMggoI6uTE9eqgIwENs0Byf7PB+uv9Oq3tXL2EU+egUH2OiAISKNp5ulC WaAp+YfMv41VsdSfL1OquzUXz87vE4kL5wItA4xM+c6+IMeJW8nVrv9BOmf34MUg kPhptnUc7TFwhk90VhI+YM8SmH9LQ1ByT7oqdbC9TGML70LJCbA8s3WlC/pxEkUC NdRRLJPCx1ryLEjky279Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudejgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeejffffgfffkeefffelgfekleetjeffleeludeghfehleffteeh veduffdugfdvnecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Feb 2024 12:01:19 -0500 (EST) From: Thomas Monjalon To: Euan Bourke , Bruce Richardson Cc: dev@dpdk.org, Stephen Hemminger Subject: Re: [PATCH v4 0/8] add new command line argument parsing library Date: Wed, 14 Feb 2024 18:01:18 +0100 Message-ID: <3702981.OBFZWjSADL@thomas> In-Reply-To: <18366886.sWSEgdgrri@thomas> References: <18366886.sWSEgdgrri@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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.