On 9/6/2024 2:11 PM, Jerin Jacob wrote: > On Fri, Sep 6, 2024 at 3:04 PM Ferruh Yigit <ferruh.yi...@amd.com> wrote: >> >> On 9/5/2024 8:58 AM, David Marchand wrote: >>> On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger >>> <step...@networkplumber.org> wrote: >>>> >>>> The API's in ethtool from before 23.11 should be marked stable. >>> >>> EAL* ? >>> >>>> Should probably include the trace api's but that is more complex change. >>> >>> 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? > > The purpose of exposing rte_eal_trace_generic_* is that, applications > can add generic trace points > in the application. >
Can't applications use 'rte_trace_point_emit_*()' directly, as libraries does?
