On Fri, 1 Aug 2025 11:37:06 +0200
Tomasz Duszynski <tduszyn...@marvell.com> wrote:
> > > Add a dummy rte_pmu_read() definition for chkincs when
> > > ALLOW_EXPERIMENTAL_API is not defined to suppress warnings from
> > > use of experimental APIs in tracepoints.
> > >
> > > Fixes: 960c43184c4d ("pmu: introduce library for reading PMU events")
> > >
> > > Signed-off-by: Tomasz Duszynski <tduszyn...@marvell.com>
> > > ---
> > > lib/pmu/rte_pmu.h | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/lib/pmu/rte_pmu.h b/lib/pmu/rte_pmu.h
> > > index 57b634ecd8..84a5d522d1 100644
> > > --- a/lib/pmu/rte_pmu.h
> > > +++ b/lib/pmu/rte_pmu.h
> > > @@ -232,6 +232,10 @@ rte_pmu_read(unsigned int index)
> > >
> > > return __rte_pmu_read_userpage(group->mmap_pages[index]);
> > > }
> > > +/* quiesce warnings produced by chkincs */
> > > +#ifndef ALLOW_EXPERIMENTAL_API
> > > +#define rte_pmu_read(pc) ({ RTE_SET_USED(pc); 0; })
> > > +#endif
> > >
> >
> > Seems like a problem that could be fixed cleaner in chkincs?
>
> I don't think there is good solution to this problem. From one angle chinkcs
> should detect
> violations to experimental api calling conventions and it does that. This
> library is injected
> into eal tracing so calling experimental api happens hence warnings are
> showing up.
>
> On the other hand adding some exception list (or whatever) to chkincs could
> encourage similar
> cases by making it a) easy b) looking clean. What I have now is at least not
> very appealing.
>
> It looks like this library is the only one non-compliant to experimental api
> calling rules so I'd
> leave that workaround as is hoping that it won't be experimental for too long.
I would rather just make some of the function non-experimental or internal.
