RE: rdma-core build environment enabling out-of-core providers

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> 
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html