> 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 My major concern was that when it comes to distros we don't have their exact code base and/or can't release it. They take rdma-core X and apply patches on it so it becomes rdma-core X.Y. Hence if I take rdma-core X and apply my changes I will be actually missing several patches. Assuming backward-and-forward support, I might as well take rdma-core X+1 and base upon it my newer patches. > 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? As I've indicated above we don't have their exact code base and/or can't release it. > 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 Thanks, Ram -- 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
