[ofiwg] lifabric provider extensions

[Reese Faucette (rfaucett)]

Well, I am throwing it out as a candidate for "standard / common practice" - I have not actually tried implementing against it or given it the depth of analysis to confidently advocating for it yet.  I think that with the "group-think" from this list we can come up with something pretty good.

Yes, probably worth also standardizing on the #defines app src code  would look for regarding extensions.

-r

> -----Original Message-----
> From: Jeff Squyres (jsquyres)
> Sent: Saturday, November 01, 2014 4:29 AM
> To: Reese Faucette (rfaucett)
> Cc: ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] lifabric provider extensions
> 
> Just to be clear: you're advocating that this become the standard / common
> practice, right?  I.e., that "fi_<provider_name>.h" be standard form for
> header files for provider-provided extensions, right?
> 
> Hence, configure-providing software can do things like AC_CHECK_HEADER
> to see if various provider extensions are available.
> 
> Is it worth having some additional #define's of a common form in
> fi_<provider_name>.h to identify what objects have extensions?  E.g.,
> fi_xyzzy.h could "#define FI_XYZZY_AV_OPS 1" so that and app can
> programmatically know that fi_ops_av_xyzzy exists.
> 
> 
> 
> On Oct 31, 2014, at 1:07 PM, Reese Faucette (rfaucett) <rfaucett at cisco.com>
> wrote:
> 
> > I have this idea of how providers might add calls in the rare event its
> needed, but would like to run it by the list for comments.
> > Let's say provider xyzzy supportsa new call AV-related call,
> "fi_av_xyzzy_add_flux()".  The would be a new header "fi_xyzzy.h" and
> "xyzzy_av.c" as shown below.
> >
> > Does this seem sane?  I think the "version" passed to fi_getinfo can be
> used to deal with fi_ops_av growing wrt. Backwards compatability.
> >
> > Thanks,
> > -reese
> >
> > ======= fi_xyzzy.h ========
> >
> > struct fi_ops_av_xyzzy {
> >        struct fi_ops_av base_ops;
> >        int (*add_flux)(struct fid_av *av, ssize_t flux_value); };
> >
> > static inline int
> > fi_av_xyzzy_add_flux(struct fid_av *av, ssize_t flux_value) {
> >        return ((struct fi_ops_av_xyzzy *)av->ops)->
> >               add_flux(av, value);
> > }
> >
> > ====== xyzzy_av.c ==========
> >
> > struct fi_ops_av_xyzzy xyzzy_av_ops = {
> >        .base_ops = {
> >               .size = sizeof(struct fi_ops_av_xyzzy),
> >               .insert = xyzzy_av_insert,
> >               ...
> >        },
> >        .add_flux = xyzzy_av_add_flux;
> > };
> >
> > int xyzzy_av_open(...)
> > {
> >        ...
> >        av->ops = (struct fi_ops_av *)&xyzzy_av_ops;
> >        ...
> >        return 0;
> > }
> >
> > _______________________________________________
> > ofiwg mailing list
> > ofiwg at lists.openfabrics.org
> > http://lists.openfabrics.org/mailman/listinfo/ofiwg
> 
> 
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/