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 9C8EEA04A3; Tue, 16 Jun 2020 17:47:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 106351BF8F; Tue, 16 Jun 2020 17:47:37 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 28A191BF89 for ; Tue, 16 Jun 2020 17:47:36 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8CA415C00DB; Tue, 16 Jun 2020 11:47:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 16 Jun 2020 11:47:35 -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=fm1; bh= 1e/gdp0Z282KzCypuF+5pcgDgj18ioxRMsceaFXYLa4=; b=MJdWRLW4ys31Zznc QmQeQdA28cd97SFKg6reiuxY7Xf0QqDvPRPxvpSrjvd95S6JIlok9k+RptBIGQb3 U7h52FRmli0relce8Y/5eceemh4X1rYVieB/iiSihCnildoMFHZsiZhty/8QOz3G q9g9JNnEZQgE5PsFafiJ1O/AvloJuiImrVeMpszYiw3jcx0v4Be+o7E/W7KKM4wf MIbdsQrO+weU4WxpTOTpomRn2dleWhWiu4IpfA5XSKGR99S7D2Dyb9uQLyZDRd5F Seh23ZGvas1d12hgLLRulMij01Edv0xmcDG+zJyRr9XHQot+5DI4nt8QZG3dx5LS LtzmUQ== 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=fm3; bh=1e/gdp0Z282KzCypuF+5pcgDgj18ioxRMsceaFXYL a4=; b=kr+aRO4K0c8802qBLqEfbwBT5NTCpC1SOefHjerIeMpQYiqIQT21ndqpj e5CCsGVwL5xaxttTWQdF8DskYdhU9Kg2+YlXUWkHnJyWxeagvVfRt7ZsOb4sGvU2 yKF0X34pizXL2OaQ9oejNcOvnQigCDyIpRCmhfDVluBBYYBvOuNLlQdpMK53GBV2 Q18os6k+anbS9WjNC5bP4jkLbCtBxfp1o0nZ4+Moc75j2ProsBxgIY4xdM1LyeSl h2Nk03T/xspTgCgHin/LLJwnbkJpRTqmf6tvirQF6MXZ4k9f//XwWdv2iuyHj9/g LVxykAiN5URPJl4kJOEEdlwPNLGyQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejtddgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 9175A328005A; Tue, 16 Jun 2020 11:47:34 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, Bruce Richardson , konstantin.ananyev@intel.com Date: Tue, 16 Jun 2020 17:47:33 +0200 Message-ID: <1818920.OYzlaK8PRP@thomas> In-Reply-To: <20200428102825.GB1897@bricha3-MOBL.ger.corp.intel.com> References: <20200212230810.2837-1-stephen@networkplumber.org> <20200427231625.10135-1-stephen@networkplumber.org> <20200428102825.GB1897@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/4] Enforce checking on flag values in API's 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" 28/04/2020 12:28, Bruce Richardson: > On Mon, Apr 27, 2020 at 04:16:21PM -0700, Stephen Hemminger wrote: > > The DPDK API's are lax about checking for undefined flag values. > > This makes it impossible to add new bits to existing API's > > without causing ABI breakage. This means we end up doing unnecessary > > symbol versioning just to work around applications that might > > pass in naughty bits. > > > > This is the DPDK analog of the Linux kernel openat() problem. > > Openat api was added but since kernel did not check flags it > > ended up that another syscall openat2() was necessary before > > the flags could be used. > > > > v3 - define mask based on existing defines for ring and hash > > > > Stephen Hemminger (4): > > ring: future proof flag settings > > hash: check flags on creation > > stack: check flags on creation > > cfgfile: check flags value > > > I think this is a good idea to do in DPDK > > Series-acked-by: Bruce Richardson Applied, thanks