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 EA683A00E6 for ; Mon, 5 Aug 2019 16:39:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DB29C1BDF1; Mon, 5 Aug 2019 16:39:16 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 3526F1BDF0 for ; Mon, 5 Aug 2019 16:39:15 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BA1C321C4E; Mon, 5 Aug 2019 10:39:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 05 Aug 2019 10:39:14 -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=mesmtp; bh=/wsfbd+paVafjBdusSemBWqSzdKjgUkG+xSVQda0SQg=; b=EFMQ+wxva9cX sBcvNivFWhYJrcZJuhVIphtXNR1d/1UWOM8uifs2820Q6nZtqw3XKdQW/p9PkU4s 0/kr0X5ySgU8qfpaGgjYF5p0SA7LB+drxilKX7Rh4fjbdafgp/he6aF1kcELg15h AtANmPBIBoy7VRr5HWrXreEe6leTa6c= 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=/wsfbd+paVafjBdusSemBWqSzdKjgUkG+xSVQda0S Qg=; b=IdlY4ed/MUoQ5Fzawgfby38W0Fxf4CXHROHhs9bURStEB4b6ZmwqM17dy RIbRBAf5EzVGg7NrC7e5N8t0MxDf7vahcROZ8GFmCJpMf6weDO9454/1dknAaE5w KEcty/Ylzs3ZRcgvfXl3tFs/UprFP1JJ2OOfiaRLgobLeNk7Vd/xyU0OQ3e4kBLy udymNZXajnHPFFIsJdsa1o+DkKyciRFuwVdTyT+bkcAEKRrLU9m9/yG9kvLQm6a6 P/6qL7Di1YYUD1nF4o0DlwjNXc+V4b8VpJqJoR8A7xx8a/nIyRStX2l5U+oWGCze oee87Bs54u83ic/99BbOd4Z9WNuQQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtjedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd 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 22BAF380083; Mon, 5 Aug 2019 10:39:13 -0400 (EDT) From: Thomas Monjalon To: David Marchand Cc: dev@dpdk.org, anatoly.burakov@intel.com, bruce.richardson@intel.com, Ray Kinsella , "Traynor, Kevin" , Stephen Hemminger Date: Mon, 05 Aug 2019 16:39:12 +0200 Message-ID: <1667146.ajMsIp94DY@xps> In-Reply-To: <1564752563-11850-1-git-send-email-david.marchand@redhat.com> References: <1564752563-11850-1-git-send-email-david.marchand@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol removal 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" 02/08/2019 15:29, David Marchand: > This symbol has been deprecated for quite some time. > Let's drop it in the next release. > --- > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* eal: The ``rte_malloc_virt2phy`` function has been deprecated and replaced > + by ``rte_malloc_virt2iova`` since v17.11 and will be removed in DPDK 19.11. For this patch and another one about removing rte_cpu_check_supported(), I have a general comment on the date of removal. As was stated recently in the contribution guide: http://git.dpdk.org/dpdk/commit/?id=7abe4a24cc "Deprecated APIs are removed completely just after the next LTS." The idea behind this policy is to avoid removals during LTS releases, in order to have at least one release before X.11 LTS for end users to prepare replacing the usage of the removed API. Does it make sense to postpone any API removal after 19.11?