[ofa-general] Re: [PATCH RFC] opensm/event_plugin: plugin API version 2

Hal Rosenstock hrosenstock at xsigo.com
Mon Jun 30 14:28:14 PDT 2008


On Mon, 2008-06-30 at 17:27 +0300, Sasha Khapyorsky wrote:
> On 04:36 Mon 30 Jun     , Hal Rosenstock wrote:
> > 
> > If this idea catches on, aside from exposing the internals in an
> > unstructured manner, I see a mix and match issue with plugins developing
> > which may lead to certain OpenSM versions being selected for
> > compatibility or worse no choice due to plugin version compatibility as
> > they get to support whatever versions they choose.
> 
> As we learned recently having structured API leads to such problems just
> well, in this case one can expect "stable API" even if it was never
> declared.

I hardly think that situation is comparable if you are referring to the
library APIs exposed inside of OpenSM for the vendors who wanted these
without OpenSM itself (for diags and ibutils).

> I think I agree with Ira - OpenSM version exact match enforcement will
> make it clearer that plugin writer should be ready to rebuild and
> possibly update its code.

should being the operative word.

> > Might this be better handled as packaging with separate packages based
> > on licenses ?
> 
> What do you mean?

This is related to what I wrote below about the OpenFabrics licensing
requirements. The idea is if GPL licensing were to be allowed (perhaps
only in some limited context), then there could be two different
packages: dual and GPL. In that way plugins would be more assured of
being compatible with each other and OpenSM.

-- Hal

> > > > You can do alot of good by making the internal APIs 'plug in like' so
> > > > adding new things doesn't require touching lots of places without
> > > > going down the whole messy road of actual dynamically loadable plug ins..
> > > > 
> > > > But if you can't identify a fixed, clean API for a dynamically
> > > > loadable plugin then you almost certainly should not have them in an
> > > > open source project...
> > > > 
> > > > This is probably better long term as far as encouraging more
> > > > contribution to opensm rather than encouraging contributions to be
> > > > kept as plugins..
> > 
> > I think this is safer from an engineering and support standpoint.
> > 
> > > GPL is some sort of an issue - OFA requires dual licensing, so GPL only
> > > code cannot enter OpenSM.
> > 
> > Yes, OFA licensing is dual BSD and GPL. Perhaps some modification is
> > needed to handle this scenario for OpenSM better. Was that
> > entertained/explored ?
> 
> Not by me.
> 
> Sasha
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general




More information about the general mailing list