On 9/6/2024 10:48 AM, David Marchand wrote: > On Fri, Sep 6, 2024 at 11:34 AM Ferruh Yigit <ferruh.yi...@amd.com> wrote: >>> On the trace API itself it should be ok. >>> The problem is with the tracepoint variables themselves, and I don't >>> think we should mark them stable. >>> >> >> We cleaned tracepoint variables from ethdev map file, why they exist for >> 'eal'? >> >> I can see .map file has bunch of "__rte_eal_trace_generic_*", I think >> they exists to support 'rte_eal_trace_generic_*()' APIs which can be >> called from other libraries. >> >> Do we really need them? >> Why not whoever calls them directly call 'rte_trace_point_emit_*' instead? >> As these rte_eal_trace_generic_*()' not used at all, I assume this is >> what done already. >> >> @Jerin, >> what do think to remove 'rte_eal_trace_generic_*()' APIs, so trace >> always keeps local to library, and don't bloat the eal .map file? > > IIRC, we still need to export them for inline helpers. >
As far as I can see they are only used for 'rte_eal_trace_generic_*()' trace helper APIs, but does eal really expose these helper APIs? Is there any other inline helpers I am missing?
