From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5B454A034F; Wed, 31 Mar 2021 23:20:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A937140ED9; Wed, 31 Mar 2021 23:20:04 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id DE1B7140EB7 for ; Wed, 31 Mar 2021 23:20:02 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DD1B65C00C3; Wed, 31 Mar 2021 17:19:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 31 Mar 2021 17:19:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= JmCl9d+6HqdcIeZF7oq7V7VV39DHricxe80+JB7KgMA=; b=u+LyoJ90zjfj6bmD sULUoN99cmvtgvDQBmTvypMi7DI6oObyZqUhG1sxW4cjovrrkILcHKY+vudJPIl2 gtRNRaJRldtqE9OuK4JvnU1QWakzd9wRWU+aCTpyt+JoTmqqCLb0Fg3altLdOsat V8IzUiAktpdlzOZwnbaIIWwTghBsUBjC36t0FMl1wtCfRnUFj7FKUJVyIDKzEO+f 1e3x2o9jebn+VASWYfHMZn/+eeVO//on02w9S8KcLTBWckUQq3ZJYsb9YhcFFWRc I8L9AbolkAdCUh1ty3JFOrIEm9gk1p4u9Ni6p8k+riq+4GKAaXAoOHAjuKEkbAtr auK4yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JmCl9d+6HqdcIeZF7oq7V7VV39DHricxe80+JB7Kg MA=; b=FQ0eb1/4xX4if34PSatWBlsM0OAnRCB/GZsGDdPID8VuC4bNuHWSzqJ0h rygD0B4RsEQQhQzr9s3L3IDt/Rmj45AaQwLLoLV2yrpFYMe+AKRlGUhcdHoZZM5x vLMNomNCcutRu2nKsCdkXjVFi25Gp+qUt+8vGXrYmHy0b8UGvYM1o5ll9Fc3p1xV hmrqNgzb5ufgw28V+Q6Ph655QfpuQTC4KqrpqimQCWOn2QdY3n/g94ViNZK+ob3Y 2zdhW8Gsb3nKtuQO7SW5Rbb1moWA0XsmrLWLmapM4cC5bQTJ+pENfY54gYiLT+Di 1iG+3FkY/1Zbg1OzkPSaXTS6VbL8A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeivddgudeigecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 44A92240054; Wed, 31 Mar 2021 17:19:58 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk , Nick Connolly Cc: dev@dpdk.org, Tyler Retzlaff , Jie Zhou , Olivier Matz , Bruce Richardson , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam Date: Wed, 31 Mar 2021 23:19:55 +0200 Message-ID: <8471582.rvcOfDAzBe@thomas> In-Reply-To: <8389a549-9aa1-5bf5-fbcc-9dffbab9fe06@mayadata.io> References: <20210320112733.13160-1-dmitry.kozliuk@gmail.com> <9009917.79gZZNtG4R@thomas> <8389a549-9aa1-5bf5-fbcc-9dffbab9fe06@mayadata.io> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 3/5] eal: make OS shims internal X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 31/03/2021 23:05, Nick Connolly: > > > This shim could have been convenient for applications. > > If not named "internal", we could export the header file > > and allow apps including it. > > > > Otherwise the app can recreate this file on its side, > > it is not a big deal. > > Opinions? > Based on my experience with SPDK, I believe this would get messy > very quickly. > > For example, a common usage is to redefine close to _close. > If the application is going to use sockets without requiring changes, > then a fake fd is needed to represent a socket and close has to > handle it as well ... which will clash with the 'simplistic' redefinition > to _close, so we'd need some way of turning these on/off > individually. > > I think there are really only two models that are viable - either an > external POSIX layer that is used by everything (in the general case, > Cygwin would be an example), or a private implementation that is > not exposed publicly. > > Keeping the implementation private is not just about keeping > POSIX out of the headers. It's about avoiding conflicts with the > application; e.g. making sure that any signal implementation can > co-exist with the application. I don't understand your point. I am just proposing to allow some apps to explicitly include the shim for their convenience in case they are fully based on DPDK and understand the risk of conflict with some other code.