[ofiwg] detecting FABRIC_DIRECT mismatch

[Jason Gunthorpe]

On Fri, May 13, 2016 at 11:25:47PM +0000, Hefty, Sean wrote:
> > > 	object->function_set->foobar(struct fi_foo *)
> > 
> > Okay, but in this case, if I follow correctly, the function that
> > returns object->function_set is actually what has changed, ie it no
> > longer returns the foobar pointer, so it should be name mangled and
> > not present at all.
> 
> I'm not sure we're on the same page yet.  Here's a specific example:

No, I get, it, the point is that this ep:

> 	return ep->msg->recv(ep, buf, len, desc, src_addr, context);

Came from some other fi_* function, that *that* function needs a
mangled name too if the DIRECT version does not return the recv
pointer.

eg, 'struct ep' has technically changed ABI (even if that just means
recv is forced to null), so the symbols that touch it need new names.

> One of the issues is that the context parameter may need to point to
> a specific data structure, which can differ between the direct and
> non-direct builds.  (It does not for the GNI provider, but does for
> B/G.)

Well, everything that works with a context parameter may need a
mangled name too, depending on how different the datastructure is (eg
a prepend approach is probably OK, an append approach is probably not
OK..)

> Requiring that providers support both direct and non-direct clients
> simultaneously is one of the options being considered.

I think if you solve all the issues with symbol naming to allow for
this, then symbols will be used properly. You don't need to require
implementing all the symbols in all the combinations at first though.

Jason