RE: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Akhil Goyal [mailto:gakhil@marvell.com]
> Sent: Thursday, 3 October 2024 09.01
> 
>  Hi Morten,
> >
> > Apologies for delayed response.
> > > Maybe a combination, returning the lowest end of the two versions
> of the list,
> > > would work...
> > >
> > > ----------------------------------
> > > Common header file (rte_common.h):
> > > ----------------------------------
> > >
> > > /* Add at end of enum list in the header file. */
> > > #define RTE_ENUM_LIST_END(name) \
> > > _ # name # _ENUM_LIST_END /**< @internal */
> > >
> > > /* Add somewhere in header file, preferably after the enum list. */
> > > #define rte_declare_enum_list_end(name) \
> > > /** @internal */ \
> > > int _# name # _enum_list_end(void); \
> > > \
> > > static int name # _enum_list_end(void) \
> > > { \
> > > 	static int cached = 0; \
> > > \
> > > 	if (likely(cached != 0)) \
> > > 		return cached; \
> > > \
> > > 	return cached = RTE_MIN( \
> > > 			RTE_ENUM_LIST_END(name), \
> > > 			_ # name # _enum_list_end()); \
> > > } \
> > > \
> > > int _# name # _enum_list_end(void)
> > >
> > > /* Add in the library/driver implementation. */
> > > #define rte_define_enum_list_end(name) \
> > > int _# name # _enum_list_end(void) \
> > > { \
> > > 	return RTE_ENUM_LIST_END(name); \
> > > } \
> > > \
> > > int _# name # _enum_list_end(void)
> > >
> > > --------------------
> > > Library header file:
> > > --------------------
> > >
> > > enum rte_crypto_asym_op_type {
> > > 	RTE_CRYPTO_ASYM_OP_VERIFY,
> > > 	/**< Signature Verification operation */
> > > 	RTE_ENUM_LIST_END(rte_crypto_asym_op)
> >
> > Will the ABI check be ok for adding anything in between
> > RTE_CRYPTO_ASYM_OP_VERIFY and
> > RTE_ENUM_LIST_END(rte_crypto_asym_op)?
> > Don’t we need to add exception for that if we somehow make it
> internal by
> > adding a comment only?
> > Library is actually not restricting the application to not use
> > RTE_ENUM_LIST_END(rte_crypto_asym_op) directly.
> >
> > Also we may need to expose the .c file internal function as
> experimental in
> > version.map
> >
> > > }
> > >
> > > rte_declare_enum_list_end(rte_crypto_asym_op);
> > >
> > > ---------------
> > > Library C file:
> > > ---------------
> > >
> > > rte_define_enum_list_end(rte_crypto_asym_op);
> >
> > If we want to make it a generic thing in rte_common.h
> > Will the below change be ok?
> > ----------------------------------
> > Common header file (rte_common.h):
> > ----------------------------------
> > #define rte_define_enum_list_end(name, last_value) \
> > static inline int name ## _enum_list_end(void) \
> > { \
> >        return last_value + 1; \
> > }
> >
> > ----------------
> > Lib header file
> > ----------------
> > //After the enum definition define the list end as below
> > rte_define_enum_list_end(rte_crypto_asym_op,
> > RTE_CRYPTO_ASYM_OP_VERIFY);
> >
> >
> > And wherever list end is needed use
> rte_crypto_asym_op_enum_list_end()?
> >
> > With this change, abi check will not complain for any new addition at
> the end of
> > enum.
> > And we do not need to expose any internal API in version.map.
> >
> Can we move forward with above suggestion?

Sorry about the late reply, Akhil.

It seems Ferruh and David have picked up this discussion with good arguments.

I have no preferences for a generic solution, especially if this is an isolated case. A generic solution can be added at any time later.