DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Nick Connolly <nick.connolly@mayadata.io>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Tal Shnaiderman <talshn@nvidia.com>,
	dev@dpdk.org, navasile@linux.microsoft.com,
	dmitrym@microsoft.com, pallavi.kadam@intel.com
Subject: Re: [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno)
Date: Tue, 17 Nov 2020 15:53:18 +0300
Message-ID: <20201117155318.48728dac@sovereign> (raw)
In-Reply-To: <92e984ae-23b1-7a44-5d8f-8d699d487115@mayadata.io>

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.

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.

  reply	other threads:[~2020-11-17 12:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-14 21:11 [dpdk-dev] [PATCH] eal/windows: definition for ETOOMANYREFS errno Tal Shnaiderman
2020-11-14 22:01 ` Dmitry Kozlyuk
2020-11-14 22:11   ` Tal Shnaiderman
2020-11-15 10:51     ` Thomas Monjalon
2020-11-15 14:23       ` Tal Shnaiderman
2020-11-14 22:21 ` [dpdk-dev] [PATCH v2] " Tal Shnaiderman
2020-11-14 23:13   ` Dmitry Kozlyuk
2020-11-15 23:10     ` Thomas Monjalon
2020-11-17 10:51       ` [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno) Nick Connolly
2020-11-17 12:53         ` Dmitry Kozlyuk [this message]
2020-11-19 13:21           ` Tal Shnaiderman
2020-11-19 14:46             ` Thomas Monjalon
2020-11-19 15:27               ` Tal Shnaiderman
2020-11-19 15:38                 ` Nick Connolly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201117155318.48728dac@sovereign \
    --to=dmitry.kozliuk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=dmitrym@microsoft.com \
    --cc=navasile@linux.microsoft.com \
    --cc=nick.connolly@mayadata.io \
    --cc=pallavi.kadam@intel.com \
    --cc=talshn@nvidia.com \
    --cc=thomas@monjalon.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git