Re: rte_bus_probe() does not exit on error

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Mon, May 02, 2022 at 11:54:29PM +0200, Thomas Monjalon wrote:
> Hello,
> 
> 02/05/2022 23:20, McDaniel, Timothy:
> > Hello DPDK community,
> > 
> > I am following up on a question/comment that I submitted on April 18, for which
> > I have not received any responses. See the original comment below for context.
> > 
> > Are there objections to modifying the behavior of rte_bus_probe() so that it propagates
> > any errors detected while processing the command line arguments? It currently ignores
> > errors and continues on, always returning success instead of any error that was returned
> > by the probe function.
> 
> You are suggesting to stop if probing of one device fails.
> I am not sure it is a good idea, because sometimes we are OK
> to proceed even if one device is missing.
> 
> We could differentiate a fatal error like parsing syntax,
> and "normal error" of a device which cannot be probed in some conditions.

a bit of a tangent but it would be nice if eal initialization wasn't
coupled to bus/device enumeration at all and instead there was more
control over bus/device enumeration where the application could choose if
it wants the error to be fatal or not .. after eal was initialized.

with it burried inside eal initialization the application has no control
over the policy to fail or not, also there are other peripherial
problems that arise due to the composition e.g. event callbacks can't
be registered until after probe from init has occurred and eal init
is completed.

it would be a huge compat break (i'm ignoring that) but so would
failing eal init for reasons it does not currently fail.