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 42CBAA034F; Mon, 22 Feb 2021 23:57:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 040CD40138; Mon, 22 Feb 2021 23:57:54 +0100 (CET) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mails.dpdk.org (Postfix) with ESMTP id 48EED4003C for ; Mon, 22 Feb 2021 23:57:52 +0100 (CET) Received: by mail-lf1-f54.google.com with SMTP id v30so8384461lfq.6 for ; Mon, 22 Feb 2021 14:57:52 -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=ixXc8aOGgI/m8dRYasMA8rAZ2XRYdv2Xy5S3f8uOF4k=; b=NtH0IMUhEE2cYCbHKu5xWbDvtlcpAtyal8sr8aFOSPNfccx8M1avNl9Qsq8FI5cqpu RKHo7Y7BnYprAirdQ6+6UvR3PdrgufbC+keDoN3BWmFw4sItC2vl7sGGdHAbv3HWguRT dqabOjqqp4vHPZNjwUOZ3oM5oIYSgMZmuhMti3uyl8akAwJzbvajBYFUvwj0un81CfTP ikrjD97XlnzVptv2/g9WKDHdlANG61ovC442o2P+NOe2vsL9x86Qiemm7TPO8YzyqlcN hr3DzyF1y3rEncdtoXKJhs867LbjzqkW6miNjULm8AjBYfuY5bm0cWwdc8M6u/5dkfSm YsZA== 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=ixXc8aOGgI/m8dRYasMA8rAZ2XRYdv2Xy5S3f8uOF4k=; b=PoEqZYRcFbVKkfJEQiF2yJTsRUVAUKAVR5qF28yYkA/03HBgWyDKUzHS7OP9qy/5SR nuu/zwSZmJR5sxCHa6uXk0SpFlZZADVl4kM72QLnpk9pw6Lj9OZcXc03GIXI8ZHPmM+c e3rSnIExp0MLv3BLiZV5veetS9msNHJf8FcwYPHmjUZ54mmstfeS1OMLudZYEyiuj7us V8ghMy09CsDPLHHN2DmeIo0sCMpBnfLFWT+hZfy02VH6uAOga0iwEDac5lkTHQjeQpCj oPh+cTdBGORuJ1vPXgLb3kzx7oT5z02SdH/Dw/njelao4WeQcLKPd5lGZdb1NfOUXiLN 3aDw== X-Gm-Message-State: AOAM532P4hs7iiSpicwpbhZiJQqygBzUOuCYbHIFtOOMtcTtoEq3FHqH 6yWgp2mB0Smg5nmz8MEM+w8= X-Google-Smtp-Source: ABdhPJyo1tOxxygdQAivF+Q9YNUC7z9pEsepTpBIlFFQfae1hZfK6eac2dD5EKgiqnAT9Do9h7DF3w== X-Received: by 2002:ac2:5194:: with SMTP id u20mr12453143lfi.331.1614034671875; Mon, 22 Feb 2021 14:57:51 -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 t8sm2173377lfr.249.2021.02.22.14.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Feb 2021 14:57:51 -0800 (PST) Date: Tue, 23 Feb 2021 01:57:50 +0300 From: Dmitry Kozlyuk To: Bruce Richardson Cc: Nick Connolly , dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori Message-ID: <20210223015750.31516c2c@sovereign> In-Reply-To: <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> <20210222142625.GA704@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-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)?