On Wed, Feb 15, 2017 at 12:26 PM, Thomas Monjalon
[off-list ref] wrote:

2017-02-15 12:08, Jan Blunck:

quoted

quoted

 int rte_eal_dev_attach(const char *name, const char *devargs)
 {
-       struct rte_pci_addr addr;
+       int ret = 1;
+       struct rte_bus *bus;

        if (name == NULL || devargs == NULL) {
                RTE_LOG(ERR, EAL, "Invalid device or arguments provided\n");
                return -EINVAL;
        }

-       if (eal_parse_pci_DomBDF(name, &addr) == 0) {
-               if (rte_eal_pci_probe_one(&addr) < 0)
+       FOREACH_BUS(bus) {
+               if (!bus->attach) {
+                       RTE_LOG(DEBUG, EAL, "Bus (%s) doesn't implement"
+                               " attach.\n", bus->name);
+                       continue;
+               }
+               ret = bus->attach(name);

Enforcing a globally unique naming scheme for the low-level device
makes this complicated for users. There are buses that enumerate the
devices just by an integer so we will have conflicts.

I think it is better to change the signature of rte_eal_dev_attach()
instead and find the correct bus based on its name. Also I believe the
API is more user friendly if we pass the complete (raw) devargs string
instead of the name/args pair.

I thought we could have a bus prefix in the name so there is no conflict.

Which raises the question of which separator to use. There are some
buses like "xen" and "xen-backend" that might clash with a simple
prefix. Also it makes is awkward to use for the case where the user is
iterating over OS filesystem data structures (directories and files):
the user probably has busname and device identification already
separate and needs to snprintf() into another buffer for our API just
for us to call sscanf() to extract the busname ...

How do you imagine the full devargs?

I'll send a patch.