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

[Hal Rosenstock]

On Wed, 2006-09-06 at 11:16, Michael S. Tsirkin wrote:
> 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.

It is another feature when this situation is encountered. It has been
encountered and will be again.

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

I've also seen other patches which do not meet this criteria go into
1.1. I know that's not a reason either.

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

We are talking about 2 different changes. I was responding to your
comment about the addition of osm_log_init_v2 not being a bug fix, not
the symver patch on top of that.

> 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

Not sure exactly what email (and comment) you are referring to here.

-- Hal