On Fri, Feb 03, 2017 at 08:04:19AM -0800, Christoph Hellwig wrote: > On Thu, Jan 26, 2017 at 10:30:05AM -0700, Jason Gunthorpe wrote: > > No, this is no longer just a provider so it doesn't get to use > > provider.map > > > > mlx5 will need its own map file and the various magic I described to > > become a proper library and a plugin at once. > > Honestly, I don't think it should be both at once. The library for > direct access needs to be in /usr/lib and the provider hidden in the > providers directory, and not export anything not in the providers API. Provider libraries don't export any symbols at all. That is the main reason having a library be both could potentially work out OK.. But it would have to be a proper /usr/lib/../ library first, and be symlinked to a provider lib name second... And they will have to make sure that dlopen figures this out and only loads one copy.. > I think what needs to happen is a new library for the direct access, > and the provider should be layered on top of it. I suspect that might just make a bigger mess, it looks like there is some sharing of internal statics and what not - so the two libraries would end up having their own private symbol interface, which is looking like be a worse situation then the above... 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
