On Wed, Jun 07, 2017 at 07:30:43AM +0000, Amrani, Ram wrote: > > 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. You should leverage your partnership program with various distributions. It will give you the actual code base, on which they are basing their packages. > > > 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
Attachment:
signature.asc
Description: PGP signature
