I didn't realize that this email didn't hit the list until today. The upstream code was updated to option 1.
The main reason to select option 2 or 3 is if we want libfabric 1.3, running with an updated application, to support an older dynamically built provider. > I have a slight preference for options #1 or #2, but I don't feel strongly > about it. Other opinions? > > -Dave > > > On Mar 9, 2016, at 6:24 PM, Hefty, Sean <[email protected]> wrote: > > > > The 1.3 libfabric release will contain the fi_trywait call. For > providers, there are a couple of options available for handling this. > > > > - The libfabric core can check that a provider supports the 1.3 API, and > reject those that don't. This is the easy button. > > > > - The fi_trywait call can include a check against the provider's fabric > ops to see if trywait was implemented. This conditional check would be in > all fi_trywait paths. > > > > - The libfabric core can wrap the provider's fabric ops with its own > copy of fabric ops. This requires mapping the provider's fabric fid to a > core fabric fid for the sake of compatibility. This is only needed for > providers asking for API < 1.3. This is the hard button. > > > > - Sean > > _______________________________________________ > > ofiwg mailing list > > [email protected] > > http://lists.openfabrics.org/mailman/listinfo/ofiwg _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
