On Wed, Apr 05, 2023 at 05:45:19PM -0700, Tyler Retzlaff wrote:
> Windows does not support versioned symbols. Fortunately Windows also
> doesn't have an exported stable ABI.
> 
> Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> functions.
> 
> Windows does have a way to achieve similar versioning for symbols but it
> is not a simple #define so it will be done as a work package later.
> 
> Signed-off-by: Tyler Retzlaff <roret...@linux.microsoft.com>
> ---
>  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 2bac2de..284c16e 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -82,8 +82,16 @@
>  /* mark the v23 function as the older version, and v24 as the default 
> version */
>  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
>  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> +#ifndef RTE_TOOLCHAIN_MSVC
>  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
>               int64_t x), rte_tel_data_add_array_int_v24);
> +#else
> +int
> +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> +{
> +     return rte_tel_data_add_array_int_v24(d, x);
> +}
> +#endif
>  
Can't see any general way to do this from the versioning header file, so
agree that we need some changes here. Rather than defining a public
funcion, we could keep the diff reduced by just using a macro alias here,
right? For example:

#ifdef RTE_TOOLCHAIN_MSVC
#define rte_tel_data_add_array_int rte_tel_data_add_array_int_v24
#else
MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
                int64_t x), rte_tel_data_add_array_int_v24);
#endif

If this is a temporary measure, I'd tend towards the shortest solution that
can work. However, no strong opinions, so, either using functions as you
have it, or macros:

Acked-by: Bruce Richardson <bruce.richard...@intel.com>

Reply via email to