On Mon, Jun 17, 2019 at 03:27:22PM -0400, Doug Ledford wrote:
> On Mon, 2019-06-17 at 18:54 +0000, Jason Gunthorpe wrote:
> > On Fri, Jun 14, 2019 at 03:00:32PM -0400, Doug Ledford wrote:
> > > On Thu, 2019-06-13 at 21:38 -0300, Jason Gunthorpe wrote:
> > > > + if (ibdev)
> > > > + ret = __ib_get_client_nl_info(ibdev, client_name,
> > > > res);
> > > > + else
> > > > + ret = __ib_get_global_client_nl_info(client_name,
> > > > res);
> > > > +#ifdef CONFIG_MODULES
> > > > + if (ret == -ENOENT) {
> > > > + request_module("rdma-client-%s", client_name);
> > > > + if (ibdev)
> > > > + ret = __ib_get_client_nl_info(ibdev,
> > > > client_name, res);
> > > > + else
> > > > + ret =
> > > > __ib_get_global_client_nl_info(client_name, res);
> > > > + }
> > > > +#endif
> > >
> > > I was trying to put my finger on something yesterday while reading
> > > the
> > > code, and this change makes it more clear for me. Do we really
> > > want to
> > > limit the info type based on ibdev? It seems to me that all global
> > > info retrieval should work whether you open a specific ibdev or
> > > not.
> >
> > Each chardev name has a specified query protocol - global chardevs
> > must not specify a ibdev, and local ones must. Each name can only be
> > global or ibdev - no mixing. Too confusing.
>
> I can see where that's the uapi as envisioned, my point though is would
> it be better to allow opening of an ibdev, retrieval of device specific
> data, and also retrieval of the available global data? It just
> prevents having to open two files to get information that isn't device
> specific. But, it's not a big deal either.
This runs on netlink, there is no 'opening the ibdev' or a 2nd
file. It is just the ibdev interface index # at this point on the same
netlink socket.
Thanks,
Jason
