> > 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'm not sure the rdma-core needs to worry about this, other than to provide a compile-time way to detect the version. IE I don't think rdma-core v15 should bother supporting out-of-tree providers that don't support the v15 provider<->libibverbs API. It would be up to the out-of-tree providers to support both v13 and v15, for example. > > 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. > Oh I'm already bothered. 😊 I will sign up for this. If I fall in and sink, hopefully Jason will fish me out of the drink. Cmake is new to me. > > > >> 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. > That's a good idea. We could also have a simple "noop" type provider that at least registers with the core but never claims any devices. This would at least verify the build/install, and provider-load by libibverbs. Steve. -- 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
