From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AD7F620A8F; Tue, 20 Mar 2018 18:50:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 20 Mar 2018 18:50:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=jw0aNBnj8j8vA9720Gjbuin32w YVIPATRXQET1M+zLM=; b=YZV4vQ1ZmbZ280BlVetoMGkg4LgSDo7vpn0EsPbPo3 6E6xHr/u11/CbENoIvKMw3qLRwsqeWCTVsNd79qPrzuHduA++Ahf2whviEI07TjI Gv0u2JtDiKJvw+8FJxIFu9WjR6n6tqOFjnNUorcWkVKwfXStVAFjC7kdvJDAlEIw U= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jw0aNB nj8j8vA9720Gjbuin32wYVIPATRXQET1M+zLM=; b=dHpTP+O0XdeB7l19pEd3F5 X7ZVrBBhl5ZSxIkeoo5YLvOeBurNCOBUGFFw9ZmERogTe6+zIpPLnoz0jDcoh/Nt kJqNO/ifNdw2U3kMKUhuTCq3Pz7aIfTD77G13x1IVAvhPJpWgdFCxWzPGrkw4WwU Cd7FD1sTXV97uNqgqVTXDpucq1P5Ek+Ldeppwhw7Ird2cgkzLRCM7lVIlgCvAspH FkBYct+gOeBRocpvKKmGNZHhQjxxEYqi5lL9776q9ItnEmIAKOj9i5U+02h0YshS 9jxACmJqnmsi7VClsyGZBzWEqrvzU6Fg0GoB2nbq9EkCf3ljHEOsrk/F+j6OzkMg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 81FAD24253; Tue, 20 Mar 2018 18:50:21 -0400 (EDT) From: Thomas Monjalon To: Arnon Warshavsky Cc: "Burakov, Anatoly" , wenzhuo.lu@intel.com, declan.doherty@intel.com, jerin.jacob@caviumnetworks.com, Bruce Richardson , ferruh.yigit@intel.com, dev@dpdk.org Date: Tue, 20 Mar 2018 23:49:59 +0100 Message-ID: <1645860.rB6cz0fKiK@xps> In-Reply-To: References: <1521581285-4709-1-git-send-email-arnon@qwilt.com> <6503395.k68LoKUDuZ@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: replace rte_panic instances to return an error value 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: , X-List-Received-Date: Tue, 20 Mar 2018 22:50:23 -0000 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)?