Re: [lttng-dev] [RFC] Deprecating RCU signal flavor

[Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>]

On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
> 
> After discussing it with Mathieu, we agree on the following 3 phases for
> deprecating the signal flavor:
> 
>   1) liburcu-signal will be implemented in term of liburcu-mb. The only
>   difference between the two flavors will be the public header files,
>   linked symbols and library name.  Note that this add a regression in
>   term of performance, since the implementation of liburcu-mb adds memory
>   barriers on the reader side which are not present in the original
>   liburcu-signal implementation.
> 
>   2) Adding the deprecated attribute to every public functions exposed by
>   the liburcu-signal flavor.  At this point, tests for liburcu-signal
>   will also be removed from the project.  There will be no more support
>   for this flavor.
> 
>   3) Removing the liburcu-signal flavor completely from the project.
> 
> Finally, here is a tentative versions release of mine for each phase:
> 
>   1) 0.15.0 [October 2023] (also TSAN support yay!)
> 
>   2) 0.15.1
> 
>   3) 0.16.0 || 1.0.0 (maybe a major bump since this is an API breaking
>   change)

There is a distinction between the version number of the liburcu project 
(0.14) and the ABI soname for the shared objects. We may be able to do 
step (3) without going to 1.0.0 (I don't see removal of the urcu-signal 
flavor a strong enough motivation for hitting 1.0.0 yet).

Technically speaking, given that we would be removing the entire 
liburcu-signal.so shared object, we would not be changing _symbols_ 
within an existing shared object, therefore I'm not even sure we need to 
bump the soname for all the other remaining shared objects.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev