Re: [PATCH v6 1/6] eal: provide rte stdatomics optional atomics API

[Thomas Monjalon <thomas@monjalon.net>]

29/09/2023 11:34, David Marchand:
> On Fri, Sep 29, 2023 at 11:26 AM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Fri, Sep 29, 2023 at 11:02:38AM +0200, David Marchand wrote:
> > > On Fri, Sep 29, 2023 at 10:54 AM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > In my opinion, our move to C11 thus makes RTE_BUILD_BUG_ON obsolete.
> > >
> > > That's my thought too.
> > >
> > > >
> > > > We should mark RTE_BUILD_BUG_ON as deprecated, and disallow RTE_BUILD_BUG_ON in new code. Perhaps checkpatches could catch this?
> > >
> > > For a clear deprecation of a part of DPDK API, I don't see a need to
> > > add something in checkpatch.
> > > Putting a RTE_DEPRECATED in RTE_BUILD_BUG_ON directly triggers a build
> > > warning (caught by CI since we run with Werror).
> > >
> >
> > Would it not be sufficient to just make it an alias for the C11 static
> > assertions? It's not like its a lot of code to maintain, and if app users
> > have it in their code I'm not sure we get massive benefit from forcing them
> > to edit their code. I'd rather see it kept as a one-line macro purely from
> > a backward compatibility viewpoint. We can replace internal usages, though
> > - which can be checked by checkpatch.
> 
> No, there is no massive benefit, just trying to reduce our ever
> growing API surface.
> 
> Note, this macro should have been kept internal but it was introduced
> at a time such matter was not considered...

I agree with all.
Now taking techboard hat, we agreed to avoid breaking API if possible.
So we should keep RTE_BUILD_BUG_ON forever even if not used.
Internally we can replace its usages.