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 7D58A439B6; Wed, 24 Jan 2024 14:34:03 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6D500402A8; Wed, 24 Jan 2024 14:34:03 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 2839940294 for ; Wed, 24 Jan 2024 14:34:02 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B93CD5C0087; Wed, 24 Jan 2024 08:34:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 24 Jan 2024 08:34:01 -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=1706103241; x=1706189641; bh=WaA7ZTj5D+1q2Pufiu+ZUkryDFjgOPeEti9j1Sb0vnU=; b= AdJNFPMgN3wn9FZcSq0WMe1AanIXjLa5Ri/LhVaT8PmAdvgqlQ+C46dRsIQVEd63 LCHsm6BKLJ7Dz5TIM0UIio7MVg3KlHH7UBuMO1txi/Stz6HF2c8wa6NNVWww6FMz EbiKCRtyBd/mfXNlSjkyPehCMiejTANUt+EmAkDcclg7Ks41X6BuyNoZWQuvbFqU H6l2yZpwrL47SmsjtDqYapJYhDo+cdygl106AQS16k6wOzwkNV54leYzNfyGUe0e ko7GFH3+NfaA9re+X+i6g3yz6mc2wc/685X6wuDqWE5kijN0k9VyQDmPRyO6nl11 25e6A3YygKvJfGfJYRqukA== 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=1706103241; x= 1706189641; bh=WaA7ZTj5D+1q2Pufiu+ZUkryDFjgOPeEti9j1Sb0vnU=; b=n PTGCpooFaavOmDbcoklvjXcBmtfGttPe7olSfi25w+4/0j7wh8zsjpDxgZXFRVtR J3nlyVgMtphk7dP5QM+cHuP9rAUL0dFJzvSzksnxiPYCJ3qceOAPVlLCGjhFwX6P veml4d6d/oHKdwZ2r05ELJSNF4+IJSHgRq1ZZltvMij0j7ODmRn5OiymTZc3+S7v 9th5pXgdxsZJ6xyKkqBqNzfAJlCYE4oZadxhPonOj72xMct0PhCDvkwOoruqcqZX lhZeUwkgYr6fyiFUDryNvJidBW8QXijjOlkXVXZBLvJkAqBbT/9njBp/xV1bKcih 0UOo8iOdEsUuPSy0AVztg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeluddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Jan 2024 08:34:00 -0500 (EST) From: Thomas Monjalon To: Euan Bourke , Bruce Richardson Cc: Stephen Hemminger , dev@dpdk.org Subject: Re: [PATCH v4 0/8] add new command line argument parsing library Date: Wed, 24 Jan 2024 14:33:59 +0100 Message-ID: <18366886.sWSEgdgrri@thomas> In-Reply-To: References: 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 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).