On Mon, Apr 30, 2018 at 08:45:10AM -0600, Jason Gunthorpe wrote: > 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. I don't see why rdmatool user should care about which driver is connected to specific ib_device. > > (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. Good, but it is orthogonal to Steve's work. > > Jason
Attachment:
signature.asc
Description: PGP signature
