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 0AF54A0A04 for ; Sun, 17 Jan 2021 18:13:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F02DC140D21; Sun, 17 Jan 2021 18:13:38 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 7DC7F140D17; Sun, 17 Jan 2021 18:13:36 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 059615C00D9; Sun, 17 Jan 2021 12:13:36 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 17 Jan 2021 12:13:36 -0500 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= cw5h3wvBhF/VeCliYBj1MUPtU+Zoj71qjFhLjYQ8an8=; b=JhMkR11r0xDyBAye I5hIb0P8YGt0zZvfNj37hMoZD2+EzwRG0uuUAW3WmPW3GMjNb42JfqncFJ2fR67M 75kJEJUz9apGTE59ZtFGpYIbawklL0jZ7GWWQa3RWubwxoqsiYeITOkGJKHXbk+d w2eJpV/uiVjS+Fc8lL09H/nz7ooTvOFFcT73fhLCqiOdDy9kDTcqyi+EKHCgCwS4 2BikyC4CaeAgoXdfI8UArHI143T6HmDaYTSwGQhPYA3dmCkSRFdpLTl9Ns4SbvJr fax4r+Ex8JnuDf9cq3E0PqGys/iAnScRR+omaT+AmSNELnEeU7N5XlAnYVlIiuhk anJHNw== 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=fm1; bh=cw5h3wvBhF/VeCliYBj1MUPtU+Zoj71qjFhLjYQ8a n8=; b=n/SzODIrs00nBVQistPshiTN4onHvZjG+vUKh9L5dixa5e2IaTfGrY3Jh z/oDuvF66JGMSoVvagm8kMtlwMU1dUHOnVdryzUsg5GdjE6HgCyF6CfxinltUi+b sT7eirilV2f1uWzldMG96Jm0ebFUwgZmy5IIwyH4eN/jynTh4WR8Lo4lmp8o9lq4 6MBGe9LrJEsYupOMLDK5vX2UhhMArykTRtztPNEm5PRp+8kSCFkaTd3rZyXj5IIy tVQmO2Rfho1IgUWwkTBfdJToGkXhYYnaJFtDjdcaealBDQi0otSitv4kvLLE5oiq 2Mktq55DpDkvkmfdqqN5bxq9vhUfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdeigddutddtucetufdoteggodetrfdotf 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 5CC1724005D; Sun, 17 Jan 2021 12:13:34 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff Cc: Bruce Richardson , Dmitry Kozlyuk , dev@dpdk.org, navasile@linux.microsoft.com, stable@dpdk.org Date: Sun, 17 Jan 2021 18:13:33 +0100 Message-ID: <10393939.85ReQY8nim@thomas> In-Reply-To: <20210115192152.GA17930@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1610414325-9104-1-git-send-email-roretzla@linux.microsoft.com> <20210114105554.GA1959@bricha3-MOBL.ger.corp.intel.com> <20210115192152.GA17930@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] eal/headers: explicitly cast void * to type * X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 15/01/2021 20:21, Tyler Retzlaff: > would you also like a patch submitted that stops installing the header. the > change will be breaking if any other consumers have made the same mistake as > we did. i'm not sure what dpdk's stance is on pulling headers back out of > public space. That's a good question. If it is described enough that it is not part of the API, I think we can stop installing the header. Anyway, our only commitment is on ABI compatibility, so it should be OK.