From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v5 04/12] eal: integrate bus scan and probe
	with EAL
Date: Tue, 03 Jan 2017 22:46:49 +0100
Message-ID: <1763533.RfUee4nzA4@xps13>
References: <1482756644-13726-1-git-send-email-shreyansh.jain@nxp.com>
 <1482758645-23057-1-git-send-email-shreyansh.jain@nxp.com>
 <1482758645-23057-5-git-send-email-shreyansh.jain@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: david.marchand@6wind.com, dev@dpdk.org
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wj0-f182.google.com (mail-wj0-f182.google.com
 [209.85.210.182]) by dpdk.org (Postfix) with ESMTP id A99773777
 for <dev@dpdk.org>; Tue,  3 Jan 2017 22:46:54 +0100 (CET)
Received: by mail-wj0-f182.google.com with SMTP id sd9so270317867wjb.1
 for <dev@dpdk.org>; Tue, 03 Jan 2017 13:46:54 -0800 (PST)
In-Reply-To: <1482758645-23057-5-git-send-email-shreyansh.jain@nxp.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-12-26 18:53, Shreyansh Jain:
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -844,6 +845,9 @@ rte_eal_init(int argc, char **argv)
>         if (rte_eal_intr_init() < 0)
>                 rte_panic("Cannot init interrupt-handling thread\n");
>  
> +       if (rte_eal_bus_scan())
> +               rte_panic("Cannot scan the buses for devices\n");

Yes, definitely. Just one scan functions which scan registered bus.

> @@ -884,6 +888,9 @@ rte_eal_init(int argc, char **argv)
>         if (rte_eal_pci_probe())
>                 rte_panic("Cannot probe PCI\n");
>  
> +       if (rte_eal_bus_probe())
> +               rte_panic("Cannot probe devices\n");
> +
>         if (rte_eal_dev_init() < 0)
>                 rte_panic("Cannot init pmd devices\n");

What is the benefit of initializing (probe) a device outside of the scan?
Currently, it is done in two steps, so you are keeping the same behaviour.

I imagine a model where the scan function decide to initialize the
device and can require some help from a callback to make this decision.
So the whitelist/blacklist policy can be implemented with callbacks at
the scan level and possibly the responsibility of the application.
Note that the callback model would be a change for a next release.