trace point symbols

[Jerin Jacob]

On Thu, Jan 12, 2023 at 3:13 PM Morten Brørup <mb at smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas at 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.

>