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

[David Marchand]

On Fri, Sep 29, 2023 at 12:26 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> 29/09/2023 11:34, David Marchand:
> > On Fri, Sep 29, 2023 at 11:26 AM Bruce Richardson
> > <bruce.richardson at 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 at 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.

So back to the original topic, I get that static_assert is ok for this patch.


-- 
David Marchand