[ofa-general] Re: [PATCH 1/10] libibmad: Clean up "new" interface

[Sasha Khapyorsky]

Hi Ira,

On 09:54 Mon 02 Mar     , Ira Weiny wrote:
> > 
> > >    Create new mad_rpc_portid(struct ibmad_port *srcport) function
> > >       which mirrors madrpc_portid(void)
> > >    Mark all "old" functions with __attribute__ ((deprecated))
> > 
> > This generates a lot of warnings right now (even after all patch series
> > applying it still have deprecated usages in libibmad itself). And this
> > is not very good. I think our flow should have opposite direction - first
> > to convert, then mark deprecated functions.
> > 
> > Now as fast workaround I can mask depreciation by macro:
> > 
> > #define DEPRECATED /* __attribute__ ((deprecated)) */
> > 
> > , and we will uncomment this when everything in tree will be converted.
> 
> What if we put this #def in the internal *.c files only?

I think it is simpler to convert them too :).

Actually what I meant is something else - the problem is that after
applying first patch in series we are getting a lot of warnings and this
leaves some history states in this half-broken state (warnings, not
an errors, but anyway). Which is not excellent by itself, but also
complicates using some debugging things like 'git bisect'. So I wanted to
mask deprecation with macro.

> Then it will give a
> warning to users but not on our internal code?  I just want to give potential
> users of the lib time and notice to change their code.

I understand this - by uncommenting DEPRECATED macro we can get all
those usages.

> > Also after looking over patch series I see that all "original" function
> > names become deprecated and replaces by its *_via() brothers. How do
> > you see the next step? Will we remove old names and have almost all API
> > calls with useless then _via suffix?
> 
> Unless you want to break the API I don't see a way around this.  "_via" or
> some other "useless" name change will have to be used?  I simply used "_via"
> because it was already there.
> 
> I don't know of many people using the lib so if you want we could just change
> the "original" functions, break the API, and bump the library version.  If you
> don't think there are many users this would be cleaner going forward.  But I
> was trying to move more slowly than that.

Ok, let's move slowly...

When the conversion will be ready we could rename the functions to its
original names and bump library version.

Sasha