From: Thomas Monjalon <firstname.lastname@example.org> To: Dmitry Kozlyuk <email@example.com>, Nick Connolly <firstname.lastname@example.org>, Tal Shnaiderman <email@example.com> Cc: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Andrey Vesnovaty <firstname.lastname@example.org>, email@example.com Subject: Re: [dpdk-dev] Windows: A fundamental issue (was eal/windows: definition for ETOOMANYREFS errno) Date: Thu, 19 Nov 2020 15:46:59 +0100 Message-ID: <2257677.iy3WzgjemN@thomas> (raw) In-Reply-To: <CY4PR1201MB2548B9B8E3A2198936738BD8A4E00@CY4PR1201MB2548.namprd12.prod.outlook.com> 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? > > 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 14:47 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 [this message] 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: 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=2257677.iy3WzgjemN@thomas \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 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 \ firstname.lastname@example.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