15/12/2022 10:44, Bruce Richardson:
> On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > For future standardization on the "uint" name for unsigned values rather
> > > than the existing "u64" one, we can for now:
> > > * rename all internal values to use uint rather than u64
> > > * add new function names to alias the existing u64 ones
> > >
> > > Suggested-by: Morten Brørup <m...@smartsharesystems.com>
> > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com>
> > > ---
> > > lib/telemetry/rte_telemetry.h | 36 ++++++++++++++++++++++++++++++++++
> > > lib/telemetry/telemetry.c | 16 +++++++--------
> > > lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++--------
> > > lib/telemetry/telemetry_data.h | 4 ++--
> > > lib/telemetry/version.map | 7 +++++++
> > > 5 files changed, 73 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> > > index c2ad65effe..60877dae0a 100644
> > > --- a/lib/telemetry/rte_telemetry.h
> > > +++ b/lib/telemetry/rte_telemetry.h
> > > @@ -8,6 +8,8 @@
> > > #ifndef _RTE_TELEMETRY_H_
> > > #define _RTE_TELEMETRY_H_
> > >
> > > +#include <rte_compat.h>
> > > +
> > > #ifdef __cplusplus
> > > extern "C" {
> > > #endif
> > > @@ -121,6 +123,22 @@ int
> > > rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
> > >
> > > /**
> >
> > when adding __rte_experimental api i have been asked to add the
> > following boilerplate documentation block. i'm not pushing it, just
> > recalling it is what i get asked for, so in case it's something we do?
> > see lib/eal/include/rte_thread.h as an example
> >
> >
> > ```
> > * @warning
> > * @b EXPERIMENTAL: this API may change without prior notice.
> > ```
> >
>
> Ok, thanks for the notice.
>
> Actually, related to this, since we are adding these functions as aliases
> for existing stable functions, I would like to see these being added not as
> experimental. The reason for that, is that while they are experimental, we
> cannot feasibly mark the old function names as deprecated. :-(
>
> Adding Thomas and David on CC for their thoughts.
Is it related to telemetry?
In general, yes we cannot deprecate something if there is no stable replacement.
The recommended step is to introduce a new experimental API
and deprecate the old one when the new API is stable.
