Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-11-24 15:45, Bruce Richardson:
> On Tue, Nov 24, 2015 at 04:29:12PM +0100, Thomas Monjalon wrote:
> > 2015-11-24 14:56, Bruce Richardson:
> > > On Tue, Nov 17, 2015 at 07:53:09AM -0800, Stephen Hemminger wrote:
> > > > On Tue, 17 Nov 2015 12:21:07 +0000
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > > > -static inline uint32_t
> > > > > +static inline int
> > 
> > Are we talking about this change only?
> > Or the move in the first patch from .c to .h?
> > 
> 
> The move is the ABI breaker.
> 
> > [...]
> > > > This breaks ABI since older application built with debug will try
> > > > and find the shared library entry for the routine.
> > > 
> > > Ok, so assuming we care about the ABI for debug builds,
> > 
> > The return type is not only for debug build?
> > 
> > > is it enough to just push a patch with a deprecation notice for this for 2.2,
> > 
> > The ABI is already broken for ethdev in 2.2.
> > So the symbol move should not hurt more.
> > And the API change (return type) should not be a big deal,
> > but at least an API change notification is required in the release notes.
> > Other opinion?
> 
> Ok, it makes sense.
> 
> > 
> > > or do I need to see about doing a new patchset with the NEXT_ABI macros
> > > included in it? My preference is obviously for the former.
> > 
> > No NEXT_ABI is required when ABI is already broken IMHO.
> 
> If ethdev ABI is already broken, then sure, this additional break for debug
> build is no big deal, I think.
> 
> I can do a respin of these two patches to include an API note for release notes.
> However, I see now that I also need to remove the functions from the map file.
> I could do with some help to make sure I do this correctly though. Reading through
> the doc on ABI versionning, it looks like I should completely move all existing
> functions from the existing release versions and move them to a new 2.2 section,
> dropping the four now-inline functions along the way. Is this the correct thing
> to do?

I think yes.
Removing some symbols means rewriting the symbol map from scratch.
But we never did it yet.