> > > 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 an awkward solution I would rather that fix chkincs
> > or restructure this.
> >
> > The way you are doing it will cause the checks for use
> > of experimental API to not work.
>
> No matter how I shuffle things around, the experimental API keeps getting 
> called from
> non-experimental code, so those warnings will show up.. Fixing chkincs would 
> mean telling it to
> skip checks for this library, which is basically what I'm already doing here.
>
> Dropping experimental tag feels too soon. The library still needs some time 
> to bake.
>
> So, unless anyone has got other ideas, which is the better trade off here: 
> yanking experimental
> tags or tweaking chkincs to ignore the library checks?

Any preference or other comments regarding that?

Reply via email to