On Tue, Apr 23, 2019 at 07:13:24PM +0200, Mattias Rönnblom wrote:
> On 2019-04-23 13:33, Neil Horman wrote:
> > On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> > > On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > > > On 2019-04-22 13:34, Neil Horman wrote:
> > > > 
> > > > > > +uint64_t __rte_experimental
> > > > > > +rte_rand(void)
> > > > > Do you really want to mark this as experimental?  I know it will
> > > > > trigger the
> > > > > symbol checker with a warning if you don't, but this function
> > > > > already existed
> > > > > previously and was accepted as part of the ABI.  Given that the
> > > > > prototype hasn't
> > > > > changed, I think you just need to accept it as a non-experimental
> > > > > function
> > > > > 
> > > > 
> > > > I'll remove the experimental tag and move it into the 19_05 section
> > > > (without suggesting it should go into 19.05). That maneuver seems not to
> > > > trigger any build warnings/errors.
> > > > 
> > > 
> > > OK, so that wasn't true. It does trigger a build error, courtesy of
> > > buildtools/check-experimental-syms.sh.
> > > 
> > > I can't see any obvious way around it. Ideas, anyone?
> > > 
> > No, we would have to waive it.
> 
> I don't understand. What do you mean?
> 
I mean we have to work around the error, understanding that its not really
experimental.  My first suggestion would be to make a commit with the symbol as
experimental, than add a new commit moving it into the proper section of the
version map

> > But its pretty clear that This function has been
> > around forever, so I think it would be worse to demote it to an experimental
> > symbol.  The only thing you're doing here is moving it from an inline function
> > (which is arguably part of the ABI, even if it never appeared as a symbol in the
> > ELF file), to a fully fleged symbol with a new implementation.
> > 
> 
> I agree it shouldn't be marked experimental. The reason for doing so was to
> avoid triggering a build error.
>