Re: [PATCH v5 5/7] bus: add helper to find a bus from a device name

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Gaëtan Rivet
Sent: Thursday, June 29, 2017 11:24 AM
To: Jan Blunck <redacted>
Cc: Thomas Monjalon <redacted>; dev <redacted>
Subject: Re: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from
a device name

On Thu, Jun 29, 2017 at 09:56:30AM +0200, Jan Blunck wrote:

quoted

On Wed, Jun 28, 2017 at 7:03 PM, Thomas Monjalon [off-list ref]

wrote:

quoted

quoted

27/06/2017 20:55, Jan Blunck:

quoted

On Wed, Jun 21, 2017 at 1:30 AM, Gaetan Rivet

[off-list ref] wrote:

quoted

quoted

quoted

quoted

 /**
+ * Find a bus capable of identifying a device.
+ *
+ * @param str
+ *   A device identifier (PCI address, virtual PMD name, ...).
+ *
+ * @return
+ *   A valid bus handle if found.
+ *   NULL if no bus is able to parse this device.
+ */
+struct rte_bus *rte_bus_from_dev(const char *str);

I still don't agree with this. The bus name should be passed
explicitly by the user of the API.

NAK.

Please explain why you think the bus name should be explicit.
If the bus is ambiguous, it can be explicited by the user.

I see some good benefits in being tolerant with the bus/device
representation. It provides a smooth transition to the bus model.

We build libraries. The applications we build with the help of those
libraries get notified by the OS about device events. Those devices
are chields of their parent bus. At the time the event is fired the OS
already knows about:

- the bus name (parent)
- the device name (child)
- additional event parameters (environment)

Blame me that I probably spent too much time with Kay Sievers and
GregKH to understand that device naming is easy to get wrong. Just
look at the hyperv device names and how they switched to the UUID
scheme. I don't think that hyperv is the only bus that uses UUID as
device identification. We should not codify a policy of how to deduce
a bus name from a given device name if that is knowledge that is
already present externally. Otherwise I fear this part of the EAL will
be subject to constant churn.

I agree in the context of device events.
But this development concerns all device identification scheme, not only
in the context of hotplug where we can retrieve events giving proper info.
It is parsing user input as well (command line or configuration).

In this user-centric device specification, the issue is that the current
model expect the user to provide the bus implicitly by using the right
parameter (--vdev, -w). This identification *cannot* stay, as those are
parsed within the EAL and specifics are getting out.

What is left is thus a choice: either

* We let the current scheme work for a time, while the EAL is being
cleaned
  out, during which we need some crutch to emulate the current behavior

* We force all users to migrate to the new format straight away with a
  full identification scheme.

I planned for both eventuality in my deprecation notice, by warning that
device parameters and definition might change this version. However, while
I thought that it was possible it would happen, I think it is best to
provide as much stability as possible while we work out the EAL internals.

This API is only there because I choose to keep backward compatibility.
A compromise might be to make it private to the EAL (I proposed it before
but no one really responded so I haven't acted on it). This would help the
future transition to the fully-qualified-device-identifier that we will
have to require from our users.

I'd like to hear from other DPDK devs as I think that surprising users is
not something that should be done lightly. I understand your concern and
am not opposed to address it.

I'm all in favour of stability and backward compatibility, so I don't like the option of forcing users to change just now - especially as the whole picture is not yet complete. Once we are sure we have a fully settled new scheme, then we can being to deprecate the old.

/Bruce