deprecation notice process / clarification
Thomas Monjalon
thomas at monjalon.net
Fri Jan 27 13:47:34 CET 2023
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.
More information about the dev
mailing list