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