19/02/2018 15:13, Matan Azrad: > Hi Wiles > > From: Wiles, Keith, Monday, February 19, 2018 3:56 PM > > > On Feb 19, 2018, at 12:03 AM, Matan Azrad <ma...@mellanox.com> wrote: > > >> Is this the type of API that needs to be marked experimental, > > > > > > I think it is relevant to any exposed API(not only for internal > > > libraries). > > > > > >> we should be able to prove these functions, correct? > > > > > > Don't we need to prove any function in DPDK? > > > What is your point? > > > > > > My point is this is a inline function and can not be placed in the .map > > file as a > > external API. > > Doesn't each API in .h file external? Why not? > If it shouldn't be external and should be in .h file, I think it should be > marked as internal, no? > > > These simple type of APIs are easy to prove and making them > > experimental seems to just cause an extra step. > > As Thomas mentioned here: > https://dpdk.org/ml/archives/dev/2018-January/087719.html > > Any new API should be experimental. > > Thomas, Is it different for .h file inline APIs?
No, it is not different for inline functions. If we are discussing the policy for every function, it is not a policy anymore :) It was agreed to notify the users of the new functions, so it gives time to confirm the function before making it "stable". Even if the function looks obvious, I think we should follow the policy. So, yes, please add the experimental tag.
