15/12/2022 07:49, Jerin Jacob:
> On Wed, Dec 14, 2022 at 5:40 PM Ferruh Yigit <ferruh.yi...@amd.com> wrote:
> >
> > On 12/14/2022 10:40 AM, Jerin Jacob wrote:
> > > On Wed, Dec 14, 2022 at 1:37 AM Ferruh Yigit <ferruh.yi...@amd.com> wrote:
> > >> 4) Why we need to export trace point variables in the .map files,
> > >> like '__rte_eth_trace_allmulticast_disable' one...
> > >
> > > If you see app/test/test_trace.c example
> > >
> > > There are two-way to operate on trace point, We need to export symbol
> > > iff we need option 1
> > >
> > > option1:
> > > rte_trace_point_enable(&__app_dpdk_test_tp);
> > >
> > > option2:
> > > rte_trace_point_t *trace = rte_trace_point_lookup("app.dpdk.test.tp");
> > > rte_trace_point_enable(trace);
> > >
> >
> > got it, do we really need direct access to trace point (option 1), I
> > would be OK to remove that option to not expose all these trace point
> > objects.
>
> Looks good to me.
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.
