Le 04/08/2017 à 13:30, Steve Wise a écrit : >> 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. It's just a matter of exporting the PACKAGE_VERSION from the CMakeLists to one the future header to install. It's not required, but I guess it'll make the job of out-of-tree providers easier if they can just adapt to the proper API depending on this. >>> 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. > noop is good for testing. A true provider would make sure we haven't missed any headers. 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
