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

[Sasha Khapyorsky]

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 ?

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.

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

Sasha