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 70BF3A034F; Mon, 22 Feb 2021 15:26:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E364540041; Mon, 22 Feb 2021 15:26:34 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 80E4A4003C for ; Mon, 22 Feb 2021 15:26:32 +0100 (CET) IronPort-SDR: y3cSSpjSFr5MVV2DLD1sq2pXd6WL0Ph0f0wdLdvPel5DSDvqKyIYXyR7TiFcwZ6FXjzTs6SfS9 NuRcpMrpaRpg== X-IronPort-AV: E=McAfee;i="6000,8403,9902"; a="184519126" X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="184519126" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 06:26:30 -0800 IronPort-SDR: vjls54S1KbscXm2wp2Giyul+vEbvcR7Ut+1rXzu2/NVw8j4aUpcpLq2REtWb0RKSMtbhQCn/eh SLDy7RpN+cYw== X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="389854066" Received: from dbjoyce-mobl1.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.16.54]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 22 Feb 2021 06:26:29 -0800 Date: Mon, 22 Feb 2021 14:26:25 +0000 From: Bruce Richardson To: Nick Connolly Cc: Dmitry Kozlyuk , dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori Message-ID: <20210222142625.GA704@bricha3-MOBL.ger.corp.intel.com> References: <20210220232910.772-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-2-dmitry.kozliuk@gmail.com> <20210222114743.GA1235@bricha3-MOBL.ger.corp.intel.com> <64c1e6c5-ce80-b550-b8ea-ad2a6bfe7505@mayadata.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64c1e6c5-ce80-b550-b8ea-ad2a6bfe7505@mayadata.io> 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" On Mon, Feb 22, 2021 at 12:48:39PM +0000, Nick Connolly wrote: > Rather than defining "rte_" versions of these functions, is it possible > just to provide the unprefixed definitions of them for internal use? > While this probably won't work for any functions used in public headers, > for any functions only used in C files, we can use meson to detect the > presence of the standard function and set a macro flag for the compatiblity > version if not present. This is something we already support for the > strlcpy/strlcat functions from libbsd, and it basically allows the > well-known (and loved?) functions to be used directly, and saves DPDK > developers having to worry about what "standard" functions can be used > directly, and which can't. > > Hi Bruce, > You're asking a really good question here that highlights a fundamental > issue: > Does the DPDK code base have an implied POSIX dependency, or should it > only > depend upon the standard C library and 'rte_ ' functions. This hasn't > been an > issue before, but Windows isn't 'POSIX' based. > Using "well-known" names for missing functions is ok where the > definitions > are in private header files, but if the headers are public, or the > implementation > is better done in a C file, then there can be a clash with the > application which > is likely dealing with the same issues. > There seem to be two viable approaches to handling this: > 1. Expect the platform to provide POSIX semantic (through an external > library > such as Cygwin). That way it becomes "an 'external' problem" and > the DPDK > can use the "well-known" names and expected behaviour. > 2. Provide the missing functionality, but wrap it in 'internal' header > files > and 'rte_' versions to avoid link errors. This is the approach that > Dmitry has > taken based on the guidance we've received. > > For background, the approach I've taken with adding Windows support to > SPDK > is to create an 'external' library ([1]https://wpdk.github.io) with > header files that > provide the missing POSIX functionality and functions with a prefix to > avoid link > errors. As a result, the whole of SPDK can now build and run unchanged. > Regards, > Nick > Whatever about the specific implementation, I'd very much like to get to the point where we don't have to do search-replace for a bunch of functions like this, not to mention that we'd need to have checkpatch rules in place to ensure that further instances are not re-introduced. 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. 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? /Bruce