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 60141A034F; Mon, 22 Feb 2021 13:48:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6AEC4013F; Mon, 22 Feb 2021 13:48:42 +0100 (CET) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mails.dpdk.org (Postfix) with ESMTP id A6B3040041 for ; Mon, 22 Feb 2021 13:48:41 +0100 (CET) Received: by mail-wr1-f66.google.com with SMTP id v1so18936186wrd.6 for ; Mon, 22 Feb 2021 04:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=egSQ7B8aTWgex4Fc1ku0CnaWYpwRBxCXSFHX1gTPVnU=; b=GBjsusIJmT1Av9xU3ww9OqiZdJGbmjOJ9WIYIy9j4YAayMXZV0YqgbOfsgPt0bS8Je 6yqqaQ7g6QEEtwkjrypRUNQLn0Fge9Q3sJ3VBQSI9edeKhxrKgkXvVizqhY3k5vYuzPR xFDd+c7GOvz7+tAYN6rMDQX3aW2lWA94L+xHP4O+L0qV99DDo6m2NBsK1SiW7jTnBgGm zv+s6t8SpubzAodrTdSJExusOpDTVLp5SxaJd8WtGJJhyiZu7MAN14fWmfZcFIvpjIll JjVd9vFe5asRihm7ymZzpp6VFUvqMN+RCnLcE0GNYRodoDxubFLVNcIp/MFv12DVL+sD NlqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=egSQ7B8aTWgex4Fc1ku0CnaWYpwRBxCXSFHX1gTPVnU=; b=jf2m12nXeKW0JtVQc8YsaEoubJY/RfYQuB54AtndfVpLO+Cm1/hoaakMswZdJ/J3E/ +yXOIYjmC8JWugw40wSZm8rIIcPUadT4xg9eTQ8qvpQqDw9timSHE7zR/3ENyo2DmNMV kmUwYzJthrWbEYVBFpNojQqjb5gaJf8lbtWQkQFRu6LVbHl2j3mGprWtYJc7zzcA9fV+ l9d16Bb0gHczqkb01e37W6v5czm6/PSgi/OnItO/9nF9hfKAOC80+GlhVsDjdV1cPmWP A056CxE7UxoAgRq33m+ZH25qONKOQcis6c+3qmP3EfgvAkfEoObET0Crl8SwXY52gUNV /zSA== X-Gm-Message-State: AOAM533s/OTRAHtEcdcfEjulAcuey6//2OotOQFeNb9rISyrtCpveG8A Z6T8KEeYSrVmEw52HDR5lSK0uA== X-Google-Smtp-Source: ABdhPJxiXNNZBeAXZQ3m6kANkPs05UnwsIONFCpZvMQoYxrzAI8e9mNa/DPuoDIKvmrd5pgPmB9Euw== X-Received: by 2002:a5d:6392:: with SMTP id p18mr8551557wru.426.1613998121385; Mon, 22 Feb 2021 04:48:41 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id b6sm14452164wrq.56.2021.02.22.04.48.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Feb 2021 04:48:40 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Bruce Richardson , Dmitry Kozlyuk Cc: dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori 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> Message-ID: <64c1e6c5-ce80-b550-b8ea-ad2a6bfe7505@mayadata.io> Date: Mon, 22 Feb 2021 12:48:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210222114743.GA1235@bricha3-MOBL.ger.corp.intel.com> Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" > 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 (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