From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id D63AA2C6E for ; Fri, 6 Oct 2017 19:34:47 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id t69so8841965wmt.2 for ; Fri, 06 Oct 2017 10:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8pVVD4/4gV1UEo+b/FaS5tUGXq3RzXWJjbzlYQnK2V4=; b=DcBNt0KQZ2O8cRPnauTV20TKcn9DAZqEOz/f3eyncum9GZsKvdjBQZ1usdHeaPWapm 7eBS+inbKgYusQ9Wp8voQ2N0Cv5qS8rkP2HFH2a3Dy/gGD3s32GtCQU3YCgT+TtTip7S iQmTrDgqQ91RSSyVvxY0JXiy6NdxVvLNlgy3sMvjRq5pqRuQ19SePKMRtvJ9bwGtXTkn YAHCefnDWpMZgORjh0GrWcxQrLysqh6FUUob/0/4TWK6GmpTbc+LO7KlTCdPn4Gf9dwb i4i1/ws2IfB97PZjYHyc8/iQsusmOXQj7NETu+tuC3arfIURAxhWfWiZ+zmDRaTrdqMk BBXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8pVVD4/4gV1UEo+b/FaS5tUGXq3RzXWJjbzlYQnK2V4=; b=fKkSekbsH07S3IviDvDZ/wYI0JuChP9Y75+diBi1uJ5iG55C98lKVRX9vZDhiqgVdl g2wn27CkSvsWPdVN5OAAMGS47NYjXxgX4zVWdoqzu9wNEjnHR+075FCBWQSjIOZ/hcQJ dZY+RREJZbXOf4EwlvYZWGDVa8p8V2yMRVbNILE7jSva1ZE5d/u4fOlcAqu4KMpHLOJS yYEYmL7nIff7uPHqVwuRgtsRqbPnkrYl0NFV0vI7AXutg4BvPsJAaUWqr1UzQbxgcfDc u5xBNxe6aEOso5gvE4LbHsc11fjqSJ79pL6ZkYSb7c3tmIe/N/HXZ9Pji0NtSAohOs5n KrqQ== X-Gm-Message-State: AMCzsaURoCVCfwERL2Dw/eS8DyjalFIOQtGI6LbfS+oNFvmylq5LnPMP UlHDbf9hxI6pl4TVknrbJQicqGgie+0fKlcIamSCsD+o X-Google-Smtp-Source: AOwi7QAnVcnwIlo+fnSXz+PCSaKqociBFy5KoS9d3eVb6RXm6aqRTWDuFtcs6oE1GXzg48n8gMa4N7GHFaQTg9GbfiU= X-Received: by 10.28.138.202 with SMTP id m193mr2640601wmd.63.1507311287505; Fri, 06 Oct 2017 10:34:47 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.140.196 with HTTP; Fri, 6 Oct 2017 10:34:46 -0700 (PDT) In-Reply-To: <10403057.Ll0Xg1E4J1@xps> References: <20170812102220.27773-1-shreyansh.jain@nxp.com> <2075457.Vvey9mxHue@xps> <10403057.Ll0Xg1E4J1@xps> From: Jan Blunck Date: Fri, 6 Oct 2017 19:34:46 +0200 X-Google-Sender-Auth: cKwkIapJUUTTEnExw-HYZVSJ5_M Message-ID: To: Thomas Monjalon Cc: Shreyansh Jain , dev , Hemant Agrawal Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail 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: Fri, 06 Oct 2017 17:34:48 -0000 On Fri, Oct 6, 2017 at 3:37 PM, Thomas Monjalon wrote: > 06/10/2017 15:12, Shreyansh Jain: >> On Friday 06 October 2017 04:51 AM, Thomas Monjalon wrote: >> > 19/09/2017 20:51, Jan Blunck: >> >> On Mon, Sep 18, 2017 at 1:36 PM, Hemant Agrawal wrote: >> >>> Tested-by: Hemant Agrawal >> >>> >> >>> >> >>> On 8/12/2017 3:52 PM, Shreyansh Jain wrote: >> >>>> >> >>>> Bus scan is responsible for finding devices over *all* buses. >> >>>> Some of these buses might not be able to scan but that should >> >>>> not prevent other buses to be scanned. >> >>>> >> >> >> >> If scanning the bus fails this is signaling an error. In that case we >> >> might even want to unregister the bus. >> > >> > A scan error seems important enough to be reported to the caller. >> > OK to continue scanning other buses, but an error code should be returned. >> >> Isn't that counter intuitive if the scanning continues after error and >> an error is expected to be returned from it? >> What if there are more than one error? Which one is reported. > > Both are reported with the same code. > Anyway, there is no way to know which bus is failing, > except from log. > Correct. Also there is no way to handle that failure except for reporting it to the log in all detail. >> As for cleanup, bus un-registration is not correct. Scan has failed, >> which might mean some assumption that bus took for scanning for devices >> doesn't exist for time being or present platform. Either way, I think >> whatever rollback needs to be done for scan failure, would be done by >> the bus->scan() implementation. >> >> Let me know what you think - I will make changes to the patch and push >> again. > > We may need more opinion here. > > Mine is that we should not hide a scan failure. Hide scan failures? Do you mean hiding it from the log? I wouldn't do that. > I would return an error code if any of the scan has failed, > but would process every scans. FWIW I agree.