| Message ID | f37477bf83a9ba1ee49fbd0de342f91ef85b4545.1537372746.git.gaetan.rivet@6wind.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Thomas Monjalon |
| Headers | show |
| Series | Implement new devargs framework | expand |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | success | coding style OK |
| ci/Intel-compilation | success | Compilation OK |
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.
diff --git a/drivers/bus/vdev/vdev_params.c b/drivers/bus/vdev/vdev_params.c index 842a4684e..2f55f451f 100644 --- a/drivers/bus/vdev/vdev_params.c +++ b/drivers/bus/vdev/vdev_params.c @@ -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; }
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(-)