[openib-general] OpenSM/osm_log API: Use symbol versions rather than polluting namespace

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting namespace
> 
> On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <halr at voltaire.com>:
> > > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting namespace
> > > 
> > > OpenSM/osm_log API: Rather than polluting the namespace with needless
> > > symbols, use symbol versions and have a versioned osm_log_init rather
> > > than adding osm_log_init_v2 as an additional API
> > > 
> > > This patch is intended to be applied to both trunk and 1.1 versions.
> > > 
> > > Signed-off-by: Doug Ledford <dledford at redhat.com>
> > > Signed-off-by: Hal Rosenstock <halr at voltaire.com>
> > 
> > This preserves the ABI, but would this not break the API?
> 
> Yes, this patch changes the API (in a most trivial way).

So all users need to change code or they won't compile against the new
library?

> > Anyway, frankly, I do not see why was osm_log_init_v2 added into 1.1 at all.
> > We are in code freeze, only critical fixes are supposed to be applied to branch
> > at this stage. How was adding osm_log_init_v2 critical?
> 
> There was a bug reported when the log filled up which started motivating
> these changes.

As I see it, a bugzilla ticket does not automatically convert feature request
into a bug report.  The issue is not exactly new, and people seem to have been
able to live with this.

The enhancement will keep opensm friendly to appliance like devices that are
single task subnet managers. fine, but OFED by default will activate opensm
without this switch.

Given all of the above, I don't see how can this be considered a critical bug
fix.

> We had just missed the rc3 window for this.

So that's a reason not to apply on branch unless it is critical.

> It is an upward compatible change so is low risk.

Not sure what do you mean by upward compatible. This API change does not seem to
be backward compatible - won't it break building dependent applications?
If so is not something you should do after code freeze.

If we care about namespace pollution that much (and I don't really see an issue)
do the changes on trunk.

> > Nor is this feature uncontroversial. Would not support for log rotation
> > be better?
> 
> Were there comments on the list before to this effect ?

Hmm. Not explicitly. There were comments this is non-standard and
will surprise system administrators if activated.
http://thread.gmane.org/gmane.linux.drivers.openib/29195/focus=29199

-- 
MST