From: Tal Shnaiderman <talshn@nvidia.com> To: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>, Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, Nick Connolly <nick.connolly@mayadata.io> Cc: "dev@dpdk.org" <dev@dpdk.org>, "navasile@linux.microsoft.com" <navasile@linux.microsoft.com>, "dmitrym@microsoft.com" <dmitrym@microsoft.com>, "pallavi.kadam@intel.com" <pallavi.kadam@intel.com>, Andrey Vesnovaty <andreyv@nvidia.com>, Asaf Penso <asafp@nvidia.com> Subject: Re: [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno) Date: Thu, 19 Nov 2020 15:27:21 +0000 Message-ID: <CY4PR1201MB254897D5236892BE4ECC84E0A4E00@CY4PR1201MB2548.namprd12.prod.outlook.com> (raw) In-Reply-To: <2257677.iy3WzgjemN@thomas> > 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. > >
next prev parent reply other threads:[~2020-11-19 15:27 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 2020-11-19 13:21 ` Tal Shnaiderman 2020-11-19 14:46 ` Thomas Monjalon 2020-11-19 15:27 ` Tal Shnaiderman [this message] 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CY4PR1201MB254897D5236892BE4ECC84E0A4E00@CY4PR1201MB2548.namprd12.prod.outlook.com \ --to=talshn@nvidia.com \ --cc=andreyv@nvidia.com \ --cc=asafp@nvidia.com \ --cc=dev@dpdk.org \ --cc=dmitry.kozliuk@gmail.com \ --cc=dmitrym@microsoft.com \ --cc=navasile@linux.microsoft.com \ --cc=nick.connolly@mayadata.io \ --cc=pallavi.kadam@intel.com \ --cc=thomas@monjalon.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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 http://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/ http://inbox.dpdk.org/dev \ dev@dpdk.org public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git