[RFC PATCH 2/7] telemetry: add uint type as alias for u64

[Tyler Retzlaff]

On Thu, Dec 15, 2022 at 09:44:49AM +0000, Bruce Richardson wrote:
> 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 <mb at smartsharesystems.com>
> > > Signed-off-by: Bruce Richardson <bruce.richardson at 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. :-(

seems reasonable to me, if they're just aliases and they haven't churned
then i don't see a reason why they need to spend time being
experimental.

> 
> Adding Thomas and David on CC for their thoughts.
> 
> /Bruce