From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: bus scan and probe never fail Date: Mon, 09 Oct 2017 21:34:29 +0200 Message-ID: <1734685.IGg5jlFBpv@xps> References: <20170812102220.27773-1-shreyansh.jain@nxp.com> <83422f57-4c0e-5806-c741-ed5ce10891b0@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Shreyansh Jain , Jan Blunck , dev@dpdk.org, Hemant Agrawal To: Don Provan Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 75D181B24E for ; Mon, 9 Oct 2017 21:34:31 +0200 (CEST) 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" 09/10/2017 20:21, Don Provan: > From: Shreyansh Jain [mailto:shreyansh.jain@nxp.com] > >... > > This is where I have disagreement/doubt. > > Reporting error code from rte_bus_scan would do two things: > > > > 1. rte_eal_init is not designed to ignore/log-only these errors - it > > would quit initialization. (But, this can be changed) > > 2. What should rte_eal_init do with this error? rte_bus_scan would have > > already printed the problematic bus->scan() failure. > > These practical problems confirm to me that the failure of a bus > scan is more of a strategic issue: when asking "which devices can > I use?", "none" is a perfectly valid answer that does not seem > like an error to me even when a failed bus scan is the reason for > that answer. > > From the application's point of view, the potential error here > is that the device it wants to use isn't available. I don't see that > either the init function or the probe function will have enough > information to understand that application-level problem, so > they should leave it to the application to detect it. Thank you Don. I think you convinced me.