[v2,04/13] bus/vdev: add device matching field driver
Checks
Commit Message
The vdev bus parses a field "driver", matching
a vdev driver name with one passed as follows:
"bus=vdev,driver=xxxx"
Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com>
---
drivers/bus/vdev/vdev_params.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
Comments
19/09/2018 18:03, Gaetan Rivet:
> The vdev bus parses a field "driver", matching
> a vdev driver name with one passed as follows:
>
> "bus=vdev,driver=xxxx"
I think the property should be "name".
We already have a "driver" category.
So it may be "bus=vdev,name=mytap/driver=tap"
Until now we were using the name of the driver as a prefix for
the device name because it was the only way of knowing the driver to use.
With a richer syntax like above, this restriction can be removed.
On Thu, Sep 20, 2018 at 06:11:44PM +0200, Thomas Monjalon wrote:
> 19/09/2018 18:03, Gaetan Rivet:
> > The vdev bus parses a field "driver", matching
> > a vdev driver name with one passed as follows:
> >
> > "bus=vdev,driver=xxxx"
>
> I think the property should be "name".
> We already have a "driver" category.
> So it may be "bus=vdev,name=mytap/driver=tap"
>
> Until now we were using the name of the driver as a prefix for
> the device name because it was the only way of knowing the driver to use.
> With a richer syntax like above, this restriction can be removed.
Do you want all buses to read the driver= key and use it to know which
driver to probe, or is it an exception of the vdev bus?
21/09/2018 13:53, Gaëtan Rivet:
> On Thu, Sep 20, 2018 at 06:11:44PM +0200, Thomas Monjalon wrote:
> > 19/09/2018 18:03, Gaetan Rivet:
> > > The vdev bus parses a field "driver", matching
> > > a vdev driver name with one passed as follows:
> > >
> > > "bus=vdev,driver=xxxx"
> >
> > I think the property should be "name".
> > We already have a "driver" category.
> > So it may be "bus=vdev,name=mytap/driver=tap"
> >
> > Until now we were using the name of the driver as a prefix for
> > the device name because it was the only way of knowing the driver to use.
> > With a richer syntax like above, this restriction can be removed.
>
> Do you want all buses to read the driver= key and use it to know which
> driver to probe, or is it an exception of the vdev bus?
Good point. Yes, if the driver= key is provided, the bus should respect it.
It may allow to have 2 different drivers supporting the same PCI ids,
and let the user override the default driver to use.
@@ -4,6 +4,7 @@
#include <rte_dev.h>
#include <rte_bus.h>
+#include <rte_bus_vdev.h>
#include <rte_kvargs.h>
#include <rte_errno.h>
@@ -11,10 +12,12 @@
#include "vdev_private.h"
enum vdev_params {
+ RTE_VDEV_PARAMS_DRIVER,
RTE_VDEV_PARAMS_MAX,
};
static const char * const vdev_params_keys[] = {
+ [RTE_VDEV_PARAMS_DRIVER] = "driver",
[RTE_VDEV_PARAMS_MAX] = NULL,
};
@@ -23,9 +26,17 @@ vdev_dev_match(const struct rte_device *dev,
const void *_kvlist)
{
const struct rte_kvargs *kvlist = _kvlist;
+ const struct rte_vdev_device *vdev;
- (void) kvlist;
- (void) dev;
+ if (kvlist == NULL)
+ /* Empty string matches everything. */
+ return 0;
+ vdev = RTE_DEV_TO_VDEV_CONST(dev);
+ /* if any field does not match. */
+ if (rte_kvargs_process(kvlist, "driver",
+ rte_kvargs_strcmp,
+ (void *)(intptr_t)vdev->device.driver->name))
+ return -1;
return 0;
}