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 E696CA04DB; Tue, 17 Nov 2020 13:53:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BFB2A37B1; Tue, 17 Nov 2020 13:53:23 +0100 (CET) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by dpdk.org (Postfix) with ESMTP id E726537B0 for ; Tue, 17 Nov 2020 13:53:21 +0100 (CET) Received: by mail-lf1-f54.google.com with SMTP id j205so29949259lfj.6 for ; Tue, 17 Nov 2020 04:53:21 -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=wTyzVY33gUiALXrB2zq/+t6+WQ2mpdd8RVV9OJHedss=; b=d0Mv9IVjk001Sx88AA3nckU+y8sPne6LUplAJPbjqBgTjWCWzFQTWkXpHIunrrNb8z yArO6SdKQ99UjmvQqAJnMKRGjpV1WTuX/tIzj9COG6vNK5qxmTboWmL8uj/isHVwK6wE ASPlyXg3igUQf61lkZ3sk38xdyhE5h9tc7eXuRg6fEDLIO5qG/PyZm/mQvRgRLpwKpzf gG7MwIuf41qzYQqT8W159i+eUp8yTttRTw7F9C/fhs+X8IofZW2MThoizHO4KwV9Ob+t J6GW1tv2Sln1hB7HNXoZAcDPgIGKTqj62ybuoHcdGid+hjrBmPmNIOJtpVqQo/ZbnhFi 2JeA== 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=wTyzVY33gUiALXrB2zq/+t6+WQ2mpdd8RVV9OJHedss=; b=osPPhox7DI/ChPIk7M3Qpl7vrmnRjsso3pydLHzzFk+nqFEis/FE87sNOI87hg/q0h juISeZtoBBvJ0dN/894kt5Q4BdescYPAaiUhP538OtSDNu3HZbMewxMxGzn3pATdu98u SvubgRh/CF2aqBiGgkMnFV1IrjF5KNZjKZzg7+0Y1MbSHQLXyPWyfSfZz0uaeMOwj05Y Kw5hDg/8KnrewUx3trtuyYVeqRG3Ns38jz1fByhRBfSYqj7JfQ1kjuc28XgT9czTxJib 7BgyTLTj3cyxhI/r4R9mAOEgk9m8leAtssobNDvOPDgRmzVjmBKzRDYU3Y5M3DhTrYpU QL1Q== X-Gm-Message-State: AOAM531gEO1Ttpky+4lCfD31SwF4sMBsB4nYhjxIJInXwYhchsxepjNG VH3ri2cG9da/GtKwba81vFk= X-Google-Smtp-Source: ABdhPJwtX7vdWiK+g7lRf7ycF7Sv8VVxeuWljr3E1AYE4fyPLyldfwLE5BsfffZgUieUqq3uq47FUA== X-Received: by 2002:a19:483:: with SMTP id 125mr1591341lfe.19.1605617600507; Tue, 17 Nov 2020 04:53:20 -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 y14sm2922967ljy.29.2020.11.17.04.53.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Nov 2020 04:53:19 -0800 (PST) Date: Tue, 17 Nov 2020 15:53:18 +0300 From: Dmitry Kozlyuk To: Nick Connolly Cc: Thomas Monjalon , Tal Shnaiderman , dev@dpdk.org, navasile@linux.microsoft.com, dmitrym@microsoft.com, pallavi.kadam@intel.com Message-ID: <20201117155318.48728dac@sovereign> In-Reply-To: <92e984ae-23b1-7a44-5d8f-8d699d487115@mayadata.io> References: <20201114211156.17196-1-talshn@nvidia.com> <20201114222129.15760-1-talshn@nvidia.com> <20201115021323.388f49da@sovereign> <2575505.0jHVfIEzSa@thomas> <92e984ae-23b1-7a44-5d8f-8d699d487115@mayadata.io> 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=UTF-8 Content-Transfer-Encoding: quoted-printable 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" Hi Nick, > This means that rte_os.h should not include POSIX/Linux definitions to=20 > avoid clashes such as the one seen with this change.=C2=A0 It's clearly n= ot=20 > sustainable if applications have to be modified every time we add more=20 > Windows support to the DPDK. >=20 > Note that this is not an isolated issue - most of the definitions in=20 > rte_os.h (redefining close, unlink, strdup etc) should not be present if= =20 > other layers (application, other libraries, etc) are to be able to=20 > 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=20 > us to make these definitions available for 'internal' use, but prevent=20 > them being visible outside of the DPDK tree.=C2=A0 If we can't wrap them = with=20 > rte_* yet, perhaps the short term solution could be as simple as setting= =20 > 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. 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.