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 03D68A054F; Tue, 16 Mar 2021 10:51:23 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82FCF24290C; Tue, 16 Mar 2021 10:51:23 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id ABDAF242905 for ; Tue, 16 Mar 2021 10:51:21 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 437435C0105; Tue, 16 Mar 2021 05:51:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 16 Mar 2021 05:51:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= GUW6qSBAEFiPPdn/Q6b/jfjdjty8+8+9WLmitArEAcw=; b=KuqS4o8BDjCc3cB7 LwKNXre5W720O2Nbh30xoe6aidYqwNYLYyyKBXxOjzfB8C+PTFZA87yLgELLbWz5 0Z1QYWdbIgPyJPLD2uulGX26XGxknLi+1lYJ7n13eeR6dWvQQvjs+lTiPOAZg/nJ JK84Vc7tiw6hu5AMidhXTNAVN5M92pUZQ14RRiiIF3Y2f1rCOjCEHFajLayS0P3x Dkv+aTypc0Fw/PMaozbIPlZ67tH9BvKjoBO2Aq3anXTq6KHgLfav+JupPOieBZ8T 4ly/FF8l/4g7eBbElpJuCLU6EKR3xZlJLTZC3GaoYnbUCXv8W1K47im4OZNxk/dG lrO3Rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=GUW6qSBAEFiPPdn/Q6b/jfjdjty8+8+9WLmitArEA cw=; b=mrWmilgE4aiyFtTTwc/t0xFnO79L/6sX+1XXQPSWIuGYnHGbOJhl1ezjB CM1Wh7PvepnAL8O0wyewfuEUhvzTzt9HINGfLxEEE6YcbBEbjoAagkJ6bKoNKbOV ty9RZVdVeBUQmcDaUvuWgKlvZqm7F3JrvAArr3uKHsEgUVLdQgdD9SHT2lLHVp7n 866sohbQGv82pAgib7W+Qgv/LM7Foko0vtYniZWfA6dUBF6F3mGJuy+SVPI8mVs0 0tLfUXnwG/DkR8u0JC+aRMYU1xJLo+JROuOonX8C61OajOyYIm+tSPWbP9Nt0Mnb kDcXvJsiO39q8c/1/A8MN6SXgWi+g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefvddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgeejfffhhfeghfetveffgeffteelveekhffghfefgedvleeuveet fffgudelvefhnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepjeejrddufe egrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3592124005A; Tue, 16 Mar 2021 05:51:19 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: Bruce Richardson , dev@dpdk.org, Nick Connolly , dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori Date: Tue, 16 Mar 2021 10:51:17 +0100 Message-ID: <6762130.3MFRFUgUZh@thomas> In-Reply-To: <20210227232327.1ac69729@sovereign> References: <20210220232910.772-1-dmitry.kozliuk@gmail.com> <20210223094502.GB79@bricha3-MOBL.ger.corp.intel.com> <20210227232327.1ac69729@sovereign> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions 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 Sender: "dev" 27/02/2021 21:23, Dmitry Kozlyuk: > 2021-02-23 09:45, Bruce Richardson: > > On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote: > > > 2021-02-22 14:26, Bruce Richardson: > > > > As you say, though, the main issue will be whether we have instances in > > > > public header files or not. I would hope that no static inline functions in > > > > DPDK use any of the functions in question, but I'm not sure. Perhaps if > > > > there are instances in public headers those could be reworked to not use > > > > the problematic functions. > > > > > > No instances of strdup(), strncasecmp(), or strtok_r() in any DPDK headers. > > > > > > > For any functions, such as strdup, which are not in a public header I would > > > > suggest the following as a possible start point, based off what was done > > > > for strlcpy. > > > > > > > > * In DPDK (probably EAL), define an rte_strdup function for use as a > > > > fallback. > > > > * Inside the meson build scripts, use "cc.has_function()" to check if the > > > > regular strdup function is available. If not, then add "-DRTE_NO_STRDUP" > > > > to the c_args for DPDK building > > > > * Inside our DPDK header (rte_string_fns.h in the strdup case), we can add > > > > a conditional define such as: > > > > #ifdef RTE_NO_STRDUP > > > > #define strdup(s) rte_strdup(s) > > > > #endif > > > > > > > > Thoughts on this? > > > > > > Looks good to me, I can rework the patchset like so. > > > > > > Policy considerations: > > > 1. The approach only applies to platform-agnostic functions, like str*(). > > > Functions like sleep() still belong to librte_eal. > > > 2. Deprecated functions, like index(3p), should be replaced > > > with alternatives suggested by the standard. > > > 3. If a standard C11 alternative is available, it should be used. > > > This mostly applies to types, like u_int32 -> uint32_t > > > (it's even in DPDK coding style already, isn't it?). > > > > > > A nit: RTE_NO_XXX -> RTE_HAS_XXX (for consistency with existing macros)? > > > > Sure, thanks. > > There's a meson issue with `cc.has_function()`: > https://github.com/mesonbuild/meson/issues/5628 The meson issue can be fixed or workarounded probably. Is it the reason for the RTE_INTERNAL proposal below? > What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h > (and other public headers if need be) to distinguish the case when it's used > from within DPDK? I'm not sure to follow the need for RTE_INTERNAL. In general, 3 guidelines: - avoid inline functions in public headers - mark exported internal functions with __rte_internal and in version.map - export internal functions in a separate file