On Tue, Jun 06, 2017 at 12:49:21PM +0000, Amrani, Ram wrote: > Hi Jason, Leon, Doug, All, > A provider's out-of-tree user library cannot be built against > rdma-core, because the API is hidden to out-of-tree libraries. This > was due to a decision taken months back. The distros have adopted > this approach as-is and it is going to be part of the next > releases. While this approach ensures all of the components are > in-sync, it has its disadvantages. > > There is typically a gap of several months between two inbox > releases. New features and fixes are delivered to the next inbox > releases, but we would like to have the ability to supply an outbox > user library to customers in between. It may also happen that > customers can only adopt the new inbox version with a delay, or even > worse, if they cannot adopt it at all due to various reasons. Two options, 1) The 'ofed' approach: just use the latest rdma-core. We want rdma-core to run on any kernel version and any distro release, so this should not be a major problem 2) For each targetted distro release back port the changes you want into the exact distro rdma-core source and distribute your driver binary from that build. This keeps everything very much the same but upgrades that driver. > How are other providers handling this? Most things I've seen have followed an OFED like approach because they also want to ship an updated kernel component. Historically we have not seen that much churn in the user space provider that is not linked to kernel changes. 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
