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

[Jason Gunthorpe]

On Fri, Jun 27, 2008 at 02:37:24PM -0700, Ira Weiny wrote:

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

Well, if you look out there, you see alot of projects that bring
everything into the same source tree, including stuff like this. It
is a reasonable thing to do if the feature is broadly useful. Exim
for instance links to a jillion libraries, including mysql - but it
does have compile time options to strip stuff out if you really care
about smallness. These days linking to some common library is not a
big problem.. The distribution has it packaged seperately and you can
just install it.
 
>    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.

How so? git makes a fork pretty easy to keep track of, and if the
plugin is tied tightly to the opensm codebase you still have to deal
with most of the same issues, like fixing 'merge conflicts' and
recompiling.

The other path many projects take is instead of adding plugins they
add a scripting language. There are many script languages that can be
embedded. Exim for instance includes perl. I'm not sure this is much
better since maintaining the script hooks is a fair amount of work as
well, but at least you get quite alot of return for your efforts..

I've often thought that a nice python mad processing library would be
hugely better than the mismash of C utilities and perl post-processing
we have today, if integrated with opensm it might just be quite the
fantastic thing. But a big project :)

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

There is also a nasty trap here, once the plugin is written there is
almost no motivation to get it into the main line. Lots of projects
seem to end up with a bundle of plugins with poor code quality ...

Anyhow, the huge thing to avoid is a fear of changing opensm because
it would break all those out of tree plugins people are using. If
things ever get to that point then adding plugin support was a huge
mistake :)

Jason