deprecation notice process / clarification

deprecation notice process / clarification

[Tyler Retzlaff]

hi,

i'm looking for some guidance when cleaning up / removing the remaining
shim functions for pthread in windows and i'm not sure how our
deprecation notice / policies apply.

windows has been providing lib/eal/windows/include/pthread.h shim that
allowed applications to use e.g. pthread_xxx functions on windows.

these shim functions were all being provided as inline functions and
were not part of the EAL api but on windows they were implicitly part of
the api surface exposed (to windows only). on posix platforms applications
did not rely on EAL for pthread abi or api (obviously).

recently we introduced a set of platform agnostic thread api in the EAL.
the functions were marked __rte_experimental as a part of new API
addition policy.

what's the most appropriate way to remove the pthread_xxx shim inline
functions from lib/eal/windows/include/pthread.h? do we have to wait the
full deprecation notice period which can't be started until we make the
new functions stable? also keeping in mind we can't actually mark inline
functions __rte_deprecated.

is this a special case where we can just rip them out and break
compilation?

input is appreciated, particularly from any consumers of the windows
port who might be unhappy.

thanks

Re: deprecation notice process / clarification

[Thomas Monjalon]

25/01/2023 23:36, Tyler Retzlaff:
> hi,
> 
> i'm looking for some guidance when cleaning up / removing the remaining
> shim functions for pthread in windows and i'm not sure how our
> deprecation notice / policies apply.
> 
> windows has been providing lib/eal/windows/include/pthread.h shim that
> allowed applications to use e.g. pthread_xxx functions on windows.
> 
> these shim functions were all being provided as inline functions and
> were not part of the EAL api but on windows they were implicitly part of
> the api surface exposed (to windows only). on posix platforms applications
> did not rely on EAL for pthread abi or api (obviously).
> 
> recently we introduced a set of platform agnostic thread api in the EAL.
> the functions were marked __rte_experimental as a part of new API
> addition policy.
> 
> what's the most appropriate way to remove the pthread_xxx shim inline
> functions from lib/eal/windows/include/pthread.h? do we have to wait the
> full deprecation notice period which can't be started until we make the
> new functions stable? also keeping in mind we can't actually mark inline
> functions __rte_deprecated.
> 
> is this a special case where we can just rip them out and break
> compilation?

Probably yes.

> input is appreciated, particularly from any consumers of the windows
> port who might be unhappy.

I think there is not too much users of Windows DPDK yet.
I would be in favor of just removing the pthread shim layer
for Windows when rte_thread equivalent is declared stable.