[dpdk-dev] [PATCH v3 00/10] Rework vdev probing to use rte_bus infrastructure

[Shreyansh Jain]

> -----Original Message-----
> From: jblunck at gmail.com [mailto:jblunck at gmail.com] On Behalf Of Jan Blunck
> Sent: Tuesday, February 28, 2017 2:49 PM
> To: Shreyansh Jain <shreyansh.jain at nxp.com>
> Cc: dev <dev at dpdk.org>; David Marchand <david.marchand at 6wind.com>; Ferruh
> Yigit <ferruh.yigit at intel.com>
> Subject: Re: [PATCH v3 00/10] Rework vdev probing to use rte_bus
> infrastructure
> 
> On Tue, Feb 28, 2017 at 9:48 AM, Shreyansh Jain <shreyansh.jain at nxp.com>
> wrote:
> > On Monday 27 February 2017 06:39 PM, Jan Blunck wrote:
> >>
> >> On Sat, Feb 25, 2017 at 11:28 AM, Jan Blunck <jblunck at infradead.org>
> >> wrote:
> >>>
> >>> With the rte_bus infrastructure present in 17.02 it is possible to
> >>> refactor
> >>> the virtual device probing into a bus. This series also introduces the
> >>> rte_vdev_device to better keep track of devices.
> >>>
> >>> This patchset depends on:
> >>> http://dpdk.org/dev/patchwork/patch/20416/
> >>> http://dpdk.org/dev/patchwork/patch/20417/
> >>>
> >>> Changes since version 2:
> >>>  * implicit bus registration through rte_eal_vdrv_register()
> >>
> >>
> >> On a second thought I don't think that this is correct though since it
> >> opens up the possibility of racing an alternative "virtual" bus. I
> >> don't think that this is a good thing though. I'll fix this in v4.
> >>
> >> Thoughts?
> >
> >
> > I prefer the RTE_REGISTER* way.
> > The issue of duplicate bus remains whether we use the macro or the
> > implicit way.
> >
> > If you use RTE_*, do you think that duplicate registration issue
> > is worth fixing?
> > (It would mean rte_bus_register to return error which the caller
> > would then need to handle).
> >
> 
> I don't think that there is a good way to handle this if we use the
> library constructors. It is better to fail the registration of the bus
> and log the error via RTE_LOG(). That introduces a dependency on the
> initialization of the logging system to be available before the
> library constructors run (before main()).

Agree. Log dependency is the tricky part. Log subsystem is in turn
dependent on users input for level.