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

Ira Weiny weiny2 at llnl.gov
Thu Jul 10 16:09:51 PDT 2008


On Wed, 09 Jul 2008 13:46:26 -0700
Hal Rosenstock <hrosenstock at xsigo.com> wrote:

> On Wed, 2008-07-09 at 07:03 +0300, Sasha Khapyorsky wrote:
> > On 06:37 Wed 02 Jul     , Hal Rosenstock wrote:
> 

<snip>

> > > > > 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.
> > > > 
> > > > I would prefer to separate packages by its functionality and not due to
> > > > licensing issues. 
> > > 
> > > Right, licensed based packages do put all related functionality in a
> > > similar bucket (management) but is that the basis to make such a
> > > decision ?
> > 
> > Which decisions? I'm not following.
> 
> The decision to expose all internals in this manner as well as the
> decision not to see what license modifications might be possible.
> 

Just to be clear I don't think having a generalized plugin is being motivated
by licensing issues (At least not for me it isn't).  I think the issue is more
a matter of distribution of functionality and ability to extend OpenSM without
affecting other users or more importantly the OFED build and install.

I had this long email written but let me try and be brief.  I think what I like
with Sashas proposal is how similar it is to the kernel.  Plugins can be added
and loaded separate from OpenSM.  If some functionality becomes "standard" and
Sasha wants to integrate it to the management git tree, it could stay as a
plugin (like kernel module) but be included with the OpenSM packages.  I don't
think that is a bad model.

Some plugins might become obsolete by interface changes but that would actually
encourage people to add them to the official build (read "git tree")_if_
_possible_.  Furthermore, now that I think about it, this could solve the
problem of using MySQL with the current plugin.  If the plugin is integrated
and compiled by default, but not installed by the user they could run _without_
MySQL installed!!!  However, it would be "automatically available" (through
OFED rpm install) to any user without them having to recompile anything!!!  I
like that!

Ira




More information about the general mailing list