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

[Ira Weiny]

On Fri, 27 Jun 2008 21:19:31 +0300
Sasha Khapyorsky <sashak at voltaire.com> wrote:

> On 10:26 Thu 26 Jun     , Hal Rosenstock wrote:
> > On Thu, 2008-06-26 at 01:23 +0300, Sasha Khapyorsky wrote:
> > > Main difference is that construct() method is renamed to create() and
> > > gets reference to osm_opensm_t object instead of just osm_log_t. This
> > > will provide to event plugin access to all OpenSM data structures and
> > > should help to create more generic plugins.
> > 
> > This exposes almost all internal data structures! While that is
> > powerful, it also could be dangerous as plugins can now more readily
> > corrupt OpenSM. It's certainly the most flexible but leaves everything
> > totally open. Is this the best approach ?

While I share your concerns, I have to admit this is a good compromise for
Sasha.

> 
> I think so. Having complicated interface instead is also error prone
> (but not flexible) implementation. I expect some level of OpenSM
> internals knowledge from plugin writers. Finally it is all in their hands.

The inflexibility has already been demonstrated when I was trying to get node
type through the interface.  Sasha did not want to have to continue to rev the
plugin interface for this.

While this open interface would allow plugins to corrupt things any plugin
could cause problems if they want to be malicious.

> 
> > If this goes ahead, versioning is an issue. Not sure osm_version is the
> > best barometer for everything. It may be for include files for building
> > a plugin but what about a coarser versioning (like library versioning) ?
> 
> 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).
> 
> > It would be nice if a single plugin can handle as many OpenSM versions
> > as possible (by something simpler than a range of osm_versions) rather
> > than needing a separate plugin per OpenSM version at the other end of
> > the spectrum.
> 
> I'm not sure that this should be hard requirement (the point of plugin
> is to not make easy life for proprietary guys, but rather to add
> possibility to extend OpenSM functionality by not directly SM related and
> so pretty optional features). I think to rebuild plugin against used
> OpenSM is acceptable. Finally it is plugin writer decision how to use
> osm_version.
> 

I think I disagree with Sasha on this one.  OpenSM should protect itself from
plugins with the wrong version.

Ira