On Mon, Apr 23, 2018 at 04:19:00PM +0300, Leon Romanovsky wrote: > > > > If you send that integer when the RDMA_NLDEV_ATTR_PROVIDER is opened > > > > then the userspace at least knows what driver sent the data.. > > > > > > > > > > The provider-specific data comes along with the core resource attributes for > > > a given resource query. It isn't like an application can query just > > > provider attributes. It queries a resource or set of them or all of them, > > > and it gets back core+provide attrs for each resource. > > > > It is not about the query, it is about having the data be > > self-describing.. There is no easy way to guess what the underlying > > device is to interpret the strings. > > Not really, in order to get data from the kernel, user will send query > with specific ib_device index and this index will be returned back. The rdma device index doesn't tell you what driver is behind this without a lot of complicated work. The driver id is intended for this purpose. (driver_id, driver_string) should uniquely describe the value returned and the driver_id needs to be available through netlink someplace > There is no need in this enum for anything except future strace support. I want to use it for driver binding in rdma-core as well. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
