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

[Ira Weiny]

On Fri, 27 Jun 2008 14:37:45 -0600
Jason Gunthorpe <jgunthorpe at obsidianresearch.com> wrote:

> On Fri, Jun 27, 2008 at 01:03:33PM -0700, Ira Weiny wrote:
> > > Then this will need to track every single data structure or API change.
> > > Plugin may require this or not, I prefer to leave this for a writer (at
> > > least now).
> 
> So what is the point of plugins if:
>  - The plugin has access to so much internal state that it must be
>    recompiled every time you change virtually any struct in opensm
>  - The plugin has no isolation from opensm so it isn't acting as a
>    fault containment or simplified API type of thing
>  - opensm is BSD licensed anyhow, so this clearly isn't for any
>    reasons of GPL avoidance or what have you.
> 
> How is this better than just patching opensm directly for people who
> want these kinds of things?

There are 2 main reasons I have here at LLNL for wanting this:

   1) (the original main reason) was because I wanted to connect OpenSM to
      MySQL.  For many a dependency on MySQL for OpenSM is unreasonable.

   2) There are concerns with how much OpenSM can/should do running on various
      types of hardware.  Here are LLNL we have some pretty beefy nodes running
      OpenSM.  (The latest has 16 cores).  Having more monitoring threads (or
      other features) is not a big deal for us.  For some, this might not be
      the case.  While features can be turned on and off with config files,
      sometimes not including code is a better solution. For example an
      embedded OpenSM?  So when we come up with some wild extension to OpenSM I
      can see some in the community not wanting it included.  Having to
      maintain a forked OpenSM source base is a pain.  Having a "plugin" which
      is compiled separately, but stand alone, is nice.

> 
> 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..

Unfortunately that is not the current state of things.  We are working toward
that, "plugin routing algo's" for example, are not really plugins.

> 
> 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...

While I agree with you there are just somethings which will never get accepted
to OpenSM.  If a plugin becomes more mainstream than hopefully that writer will
be able to integrate it, and I think Sasha would encourage it.

> 
> This is probably better long term as far as encouraging more
> contribution to opensm rather than encouraging contributions to be
> kept as plugins..
> 

Yes this might cause some people not to contribute.  However, I think many
already are already not contributing and just maintaining forked versions.
While my intentions with a plugin interface are not to make current
"non-contributor" lives easier perhaps it will make future potential
contributors lives easier and they can be brought into the mainstream?

Does this help?
Ira