On Thu, Jan 12, 2023 at 3:13 PM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Thursday, 12 January 2023 10.11 > >
> > > > I would like to see a policy regarding trace symbols. > > If we decide option 1 is not so useful, > > then we should not export trace symbols at all and document this > > policy. > > Also there are some trace symbols which could be cleaned up. I can send a patch to remove existing exposed symbols for option 1 in DPDK repo. But, Is n't an ABI break? The only downside, I can think of, is that a few more entries in version.map file. I don't have a strong option one way, either. Let me know what you think? If we decided to remove then, In https://doc.dpdk.org/guides/prog_guide/trace_lib.html, There is NOTE section as following, I can remove that as well. -- The RTE_TRACE_POINT_REGISTER defines the placeholder for the rte_trace_point_t tracepoint object. The user must export a __<trace_function_name> symbol in the library .map file for this tracepoint to be used out of the library, in shared builds. For example, __app_trace_string will be the exported symbol in the above example. --- > > +1 for not exposing trace point symbols at all. > > The trace point symbols are only used internally by DPDK, so they should not > be part of DPDK's public API. > > It might also make it easier for Bruce to move the trace library out of EAL. > > I'm not familiar with the CTF format, but I assume that if we don't expose > the trace point symbols, the trace points can still be identified when > parsing the trace file. Yes. It won't impact. The only use case for option 1 is to avoid named lookup. >
