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.
