My vote is to modify the fi_alias call such that it applies to any fid object.
fi_alias(fid_t *fid, fid_t *alias_fid, uint64_t flags); In addition, we can add fi_ep_alias() as you suggested. This breaks ABI, but I think the impact is minimal. On 4/12/16, 3:25 PM, "ofiwg on behalf of Jose, Jithin" <[email protected] on behalf of [email protected]> wrote: >We have fi_alias defined as the following: > >int fi_alias(struct fid_ep *ep, fid_t *alias_ep, uint64_t flags); > >But, this could be annoying for the applications to use the ‘alias_ep', since >all the tx/rx operations use struct fid_ep*. Apps will have to either do a >“container_of” and get back fid_ep*, or cast fid_ep to fid_t* in the fi_alias >call (since struct fid is the first element in struct fid_ep). Both these >options does not look very clean. > > >Instead, should we change the API as fi_ep_alias with the following signature? >int fi_ep_alias(struct fid_ep *ep, struct fid_ep **alias_ep, uint64_t flags); > >This will break ABI compatibility, but not sure if there are any applications >that currently use fi_alias. >Another option is to keep fi_alias and add the new API fi_ep_alias (which >internally calls fi_alias). > >Any thoughts/preferences? > >Regards, >- Jithin >_______________________________________________ >ofiwg mailing list >[email protected] >http://lists.openfabrics.org/mailman/listinfo/ofiwg _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
