From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: replace rte_panic instances to return an error value Date: Tue, 20 Mar 2018 23:49:59 +0100 Message-ID: <1645860.rB6cz0fKiK@xps> References: <1521581285-4709-1-git-send-email-arnon@qwilt.com> <6503395.k68LoKUDuZ@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Burakov, Anatoly" , wenzhuo.lu@intel.com, declan.doherty@intel.com, jerin.jacob@caviumnetworks.com, Bruce Richardson , ferruh.yigit@intel.com, dev@dpdk.org To: Arnon Warshavsky Return-path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 630A55F17 for ; Tue, 20 Mar 2018 23:50:23 +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" 20/03/2018 23:42, Arnon Warshavsky: > > Thanks for working on this important topic. > > With pleasure :) > > > My feeling is that we could replace most of them by a log + return. > > I did not think you would add a new macro. Why you chose this way? > > This was meant to keep the code shorter, and imply to the reader that this > return is actually meant to be fatal > > > > > I would like to define a device health state that can be monitored from > > > the side,and this will be an independant patch. > > > > You mean when a device become unusable? > > Yes. Obviously not a simple issue, but essential for refraining from panic > in the interrupt/data-path context, > while allowing to detect and execute on the slow/management path. > > > > - Some previously panicing void functions where changed to return a > > > value, with callers modified accordingly. > > > > If the function is exposed to the application, I think it is an ABI change > > and should follow the deprecation process. > > In this case I thought there would be no actual change for the user as the > transition is from returning void to int, > and existing calls should continue to behave as before (except for not > crashing) You are talking about API, and I agree the old applications can keep considering the functions as void. But I was talking about ABI, meaning: can we use an old application without recompiling and update only the DPDK (in .so file)?