On Tue, Jun 27, 2017 at 05:05:14PM +0200, Gaëtan Rivet wrote:
> On Tue, Jun 27, 2017 at 02:54:34PM +0100, Bruce Richardson wrote:
> > On Mon, Jun 26, 2017 at 02:22:02AM +0200, Gaetan Rivet wrote:
> > > From: Jan Blunck <jblu...@infradead.org>
> > >
> > > Signed-off-by: Jan Blunck <jblu...@infradead.org>
> > > Signed-off-by: Gaetan Rivet <gaetan.ri...@6wind.com>
> > > ---
> > > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
> > > lib/librte_eal/common/eal_common_bus.c | 24
> > > +++++++++++++++++++++++
> > > lib/librte_eal/common/include/rte_bus.h | 26
> > > +++++++++++++++++++++++++
> > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
> > > 4 files changed, 52 insertions(+)
> > >
> > > diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > index f1a0765..21640d6 100644
> > > --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > @@ -164,6 +164,7 @@ DPDK_17.05 {
> > >
> > > rte_bus_find;
> > > rte_bus_find_by_device;
> > > + rte_bus_find_device;
> > > rte_cpu_is_supported;
> > > rte_log_dump;
> > > rte_log_register;
> > > diff --git a/lib/librte_eal/common/eal_common_bus.c
> > > b/lib/librte_eal/common/eal_common_bus.c
> > > index d208214..63fd9f1 100644
> > > --- a/lib/librte_eal/common/eal_common_bus.c
> > > +++ b/lib/librte_eal/common/eal_common_bus.c
> > > @@ -190,3 +190,27 @@ rte_bus_find_by_device(const struct rte_device *dev)
> > > {
> > > return rte_bus_find(bus_find_device, (const void *)dev, NULL);
> > > }
> > > +
> > > +struct rte_device *
> > > +rte_bus_find_device(rte_dev_cmp_t cmp, const void *data,
> > > + const struct rte_device *start)
> >
> > One additional suggestion: might it be worthwhile also returning the bus
> > for the device here, in an optional 4th parameter. This is, after all,
> > a bus API. :-)
> >
> > /Bruce
>
> I think having the bus is a good info.
> However,
>
> 1. This makes this API slightly less clean I think.
> A subjective matter, but I don't like adding cruft without good
> justification.
>
> 2. The bus will be made accessible by my future patches. The series
> afterward are introducing a generic device type representation, which
> is composed of the bus. This type info is integral to the device and
> thus the bus can be read from within the resulting rte_device here.
>
So the device will contain a pointer to it's parent bus? If so, then ok,
let's leave out the extra parameter.
/Bruce
> So, I won't add this parameter right now. If we have issues with the
> rte_devargs series, it might be interesting to come back on this and
> edit this API.
>
> --
> Gaëtan Rivet
> 6WIND
