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 61D45A056A; Sat, 27 Feb 2021 21:23:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E758A22A249; Sat, 27 Feb 2021 21:23:30 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id A0A0D40146 for ; Sat, 27 Feb 2021 21:23:29 +0100 (CET) Received: by mail-lj1-f181.google.com with SMTP id p15so5786635ljc.13 for ; Sat, 27 Feb 2021 12:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5HYRAEhy8K0e5rdNIuhSUF49QsbS7hj9W8+YXbGyZy0=; b=sHHLMs+W4dIZlwsBaPM0OsogRqNFWQRFe4soQ2X9WDnLAM90c8kvFluEIKMBmqDOov h67aGmKcIWeLZ7HfuWXgC0H8DRg8nJthDD0+1xnsPHNCLcp0WIQjAE+rspDF+m9v7xlx 45H4ZtK4f5VbC7NRyRnJKmBmhBIJJigva2vQ65SgisqHqK+F/zuorYP5Uc1gzs7VBWIs 3NlP1LE9Ydo6m/jYfpntpamVam3a95pXig8URA84yMDwBEN5xL0wnpXKFUm01SoYRzcq YcleGgri0yZtMpfAtYSQ10Do/JyfPWcMD6OYI9cy214GVPvXN0ANe4PgJe17WNXnKDdJ b4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5HYRAEhy8K0e5rdNIuhSUF49QsbS7hj9W8+YXbGyZy0=; b=Z/+hJAQmOIKnJgRffZAaxPTKdm6A1uoE+XnNiGQTDEvDP0OPfeuumAx4UQFHpm682c nyzJP3kAZz8Atpk/szaAuJ2TYTKSuJBs7S9KFPhDn1P12U2KfrJELHWVhBSaJbang2bE i7ul7SZ8WxyfQNTfspd5fr4ejuhog+lz7N8uq50aTK+201+BPkHq0mp5CRt0s2epa+yc m5IZazkIklg12AgcP5kduJweKhby+FLRTg0EuZr7SjCi+j6zApIYSV0TMCYiEnxpM0Kb bQeDLfW2uCpS3Q3gOo0jsetN7TUETI8NAECQQZhRa2ouzSlGXVRL0Z4Qxfj+5DZO7jZu y/cg== X-Gm-Message-State: AOAM531KJ4AtfEjZGv6+mOs8JQlxHK3dpSDeniZwcWzgzbiU++tzDVLT WqDe2EXYWRgBScux52YWr4o= X-Google-Smtp-Source: ABdhPJxb4T28BhrvHNW5HFu9j/N2mQSYBS9WjOpZPMErbpcaqJR/dkan+C4gbMeX/jCmh6/Ku1GtSg== X-Received: by 2002:a2e:a58c:: with SMTP id m12mr5197256ljp.444.1614457409191; Sat, 27 Feb 2021 12:23:29 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id w10sm1874780lji.46.2021.02.27.12.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Feb 2021 12:23:28 -0800 (PST) Date: Sat, 27 Feb 2021 23:23:27 +0300 From: Dmitry Kozlyuk To: Bruce Richardson Cc: Nick Connolly , dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori Message-ID: <20210227232327.1ac69729@sovereign> In-Reply-To: <20210223094502.GB79@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> <20210222142625.GA704@bricha3-MOBL.ger.corp.intel.com> <20210223015750.31516c2c@sovereign> <20210223094502.GB79@bricha3-MOBL.ger.corp.intel.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" 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 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?