Le 03/08/2017 à 19:07, Jason Gunthorpe a écrit : > On Thu, Aug 03, 2017 at 05:01:16PM +0200, Nicolas Morey-Chaisemartin wrote: > >> I haven't looked into the build system but isn't this something the >> devel rpm could provide ? > Conceptually, perhaps, but someone has to figure out how to split out > the necessary cmake bits into something reusable, it is no longer > entirely trivial :) Yes, this is going to take some time. > Also don't forget that the internal API inside the header files > changes, a provider that has been modified for rdma core 15 will not > compile on rdma core 13, just like the kernel.. I guess there are enough VERSION defines in rdma-core to make the provider portable. But yes, supporting multiple versions is a lot more work. > I just wonder if it is worth the all the proposed work, I expect out > of tree providers to be very rare and temporary things. The lazy (smart?) thing to do here is to wait for an out-of-tree provider to need it (Steve ?) and give them some support to do it. If they can't be bothered, it's probably not worth it. If they want it, they'll do most of the work and the feature gets upstreamed. > >> If this is done upstream once and for all, and not by every >> out-of-tree provider, it is not fragile anymore. > Someone would also have to contribute some kind of test infrastructure > to keep it working for upstream.. If it doesn't run in cbuild I don't > test it :P It shouldn't be too hard to automatically extract one of the in-tree provider and try to compile it as an out-of-tree. And this way it's always up-to-date for testing. Nicolas -- 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
