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