From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 18551A04DD; Thu, 19 Nov 2020 16:38:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A1096F3E; Thu, 19 Nov 2020 16:38:28 +0100 (CET) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by dpdk.org (Postfix) with ESMTP id F28BBDED for ; Thu, 19 Nov 2020 16:38:25 +0100 (CET) Received: by mail-wr1-f44.google.com with SMTP id l1so6864396wrb.9 for ; Thu, 19 Nov 2020 07:38:25 -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-transfer-encoding:content-language; bh=fM4HaDE1siqAqU+FAXgfgKI1rG/C6UijxDfd7dkutXk=; b=fBYUejxnX7S5aj2cj07Q2MgkFPAnMqwypFaKrX93rArFbctyzIXf0j0saLNUC8AfgF Y1AIOX/0t5mCLFE8NGJRy1RpOxz1klj8LlXiBop0IG1tpV9s8Lp3/KdWqQwBoHJJSUK5 Ed4Kc3DgMitn65ldyX7RJzMtjrCnGioPBFXNUMg5f4hawDmhpkcjqX28oZ51yLGyQmpn WZ+Y7ZDSUTSEJ5SVgSsIVtcLq6I13jfdLPH4bg6MP/Th4pAOkGPDcnOusvtrYkDbDUoo DzOHrqDUVOB8yZuohQZScrlqUCB9zZ2XDIHZ+IvbH44F/vYS7rF7Rim84HkBgqbeCPv8 G0gA== 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-transfer-encoding :content-language; bh=fM4HaDE1siqAqU+FAXgfgKI1rG/C6UijxDfd7dkutXk=; b=A/Z8wWOuYzCTpbEEXwU+kew2+5XLuPjujWhxOlxzrnT8KsG7tRd27j/NY164XwA4F2 seUJXPWdBAZPV/4UJ01eFp7lDvjYlni+AB0BSKUYadamukypq8JOkQHxEHeSnp5SoFKM CjgqWVP6xa4fGDxX6hKyY9aUis49QvfPbdoxJgmt0o1g/b/+B4+hYrFvHwKMM+29LKh3 tITkql/ByCIqC0rRZlMpqPPaHcxBqPaaRZ3k74sA3k+qJ7BypIUFknXiCLmJAblnZkxv 4L/yWfrTwvNbGpwTDVw36Vq/dksyQv4m0uAWVILjRkdBnWUUIl/ghdWcygeVsr5HQPEg r2qw== X-Gm-Message-State: AOAM533fpVgDNbryKJs1+C/XJC5bQAAZ+t6xAr0P1Ev6sPka9HaGJpzU mdc0EXSKIj19IG1bEKMzZWACcQ== X-Google-Smtp-Source: ABdhPJwtLEAsyizD9aTQyiH0PnI1hnfvblVCWhcU0smpJfT4R0VBATIar90x+F3s12p9xzSrj7Jx2w== X-Received: by 2002:a05:6000:1150:: with SMTP id d16mr10419810wrx.320.1605800304557; Thu, 19 Nov 2020 07:38:24 -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 s202sm306860wme.39.2020.11.19.07.38.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 07:38:23 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Tal Shnaiderman , NBU-Contact-Thomas Monjalon , Dmitry Kozlyuk Cc: "dev@dpdk.org" , "navasile@linux.microsoft.com" , "dmitrym@microsoft.com" , "pallavi.kadam@intel.com" , Andrey Vesnovaty , Asaf Penso References: <20201114211156.17196-1-talshn@nvidia.com> <20201117155318.48728dac@sovereign> <2257677.iy3WzgjemN@thomas> Message-ID: <209afd2b-b31a-6c39-6391-4df3e9b673de@mayadata.io> Date: Thu, 19 Nov 2020 15:38:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Thanks Tal. On 19/11/2020 15:27, Tal Shnaiderman wrote: >> Subject: Re: Windows: A fundamental issue (was eal/windows: definition for >> ETOOMANYREFS errno) >> >> External email: Use caution opening links or attachments >> >> >> 19/11/2020 14:21, Tal Shnaiderman: >>>> Subject: Re: Windows: A fundamental issue (was eal/windows: >>>> definition for ETOOMANYREFS errno) >>>> >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> Hi Nick, >>>> >>>>> This means that rte_os.h should not include POSIX/Linux >>>>> definitions to avoid clashes such as the one seen with this >>>>> change. It's clearly not sustainable if applications have to be >>>>> modified every time we add more Windows support to the DPDK. >>>>> >>>>> Note that this is not an isolated issue - most of the definitions >>>>> in rte_os.h (redefining close, unlink, strdup etc) should not be >>>>> present if other layers (application, other libraries, etc) are to >>>>> be able to implement their own POSIX/Linux support. >>>> The purpose of rte_os.h must be clarified. It now says: >>>> >>>> /** >>>> * This is header should contain any function/macro definition >>>> * which are not supported natively or named differently in the >>>> * ... OS. Functions will be added in future releases. >>>> */ >>>> >>>> This doesn't specify if the file should expose wrappers or POSIX-named >> bits. >>>> Linux and FreeBSD, however, only use it for RTE_CPU_xxx() macros for >>>> CPU_xxx() and don't define anything with POSIX names. So should >> Windows. >>>>> Please can we back this change out until we have a strategy that >>>>> allows us to make these definitions available for 'internal' use, >>>>> but prevent them being visible outside of the DPDK tree. If we >>>>> can't wrap them with >>>>> rte_* yet, perhaps the short term solution could be as simple as >>>>> setting RTE_DEFINE_POSIX when building DPDK code and hiding them >>>>> if it is >>>> not set? >>>> >>>> You need the same value both inside DPDK to return it and outside of >>>> DPDK to match on it. Returning an unnamed, unspecified code is not an >> option. >>>> RTE_ prefix is a way to go. We can just rename ETOOMANYREFS. >>> Thanks for the info Nick. >>> Dmitry, If we go with RTE_ETOOMANYREFS, I assume we need to define it >> for Linux and FreeBSD as well? >> >> Or we can use a "more standard" error code? >> > Right, Since it is used rarely and only in our PMD I'll work with the developer on selecting a different errno and will revert this commit, apologies for the inconvenience. > >>>> Strictly speaking, C standard defines very few errno, so using POSIX >>>> values in API is incorrect anyway. It has to be deprecated and >>>> removed eventually, we already had issues with MMAP_FAILED. >>