From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: register rte_panic user callback Date: Wed, 07 Mar 2018 16:04:44 +0100 Message-ID: <35390785.Gg18XPo1UR@xps> References: <1520360928-9375-1-git-send-email-arnon@qwilt.com> <4197355.YAsZy1EAlL@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Burakov, Anatoly" , Bruce Richardson , dev@dpdk.org To: Arnon Warshavsky Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1CF3C5B30 for ; Wed, 7 Mar 2018 16:04:47 +0100 (CET) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 07/03/2018 12:02, Arnon Warshavsky: > > > Can this really go into current release without deprecation notices? > > > > If such an exception is done, it must be approved by the technical board. > > We need to check few criterias: > > - which functions need to be changed > > - how the application is impacted > > - what is the urgency > > > > If a panic is removed and the application is not already checking some > > error code, the execution will continue without considering the error. > > > > > Some rte_panic could be probably removed without any impact on > > applications. > > Some rte_panic could wait for 18.08 with a notice in 18.05. > > If some rte_panic cannot wait, it must be discussed specifically. > > > > Every panic removal must be handled all the way up in all call paths. > If not all instances can be removed at once in 18.05 (which seems to be the > case) > maybe we should keep the callback patch until all the remains are gone. Why introducing a new API for a temporary solution? It has always been like that, so the remaining occurences could wait one more release, isn't it?