Re: [PATCH v2 00/20] Enable lock annotations on most libraries and drivers

[David Marchand <david.marchand@redhat.com>]

On Mon, Apr 3, 2023 at 5:37 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> On Mon, Apr 03, 2023 at 12:52:06PM +0200, David Marchand wrote:
> > Hello Tyler,
> >
> > On Thu, Mar 2, 2023 at 9:52 AM David Marchand <david.marchand@redhat.com> wrote:
> > > On Mon, Feb 27, 2023 at 5:13 PM Gaëtan Rivet <grive@u256.net> wrote:
> > > > Ah ok, so if I understand correctly, DPDK would need to declare some
> > > > '__rte_lockable rte_mutex' and associated functions for transparent support,
> > > > to wrap above the pthread API.
> > >
> > > Yes, this is what I had in mind for the mid/long term but it was too
> > > late for 23.03 after -rc1.
> > >
> > > The Windows porting effort will probably need this abstraction too as
> > > we are trying to stop relying on the pthread API.
> > > I don't see this item in Microsoft roadmap, though.
> >
> > Do you have an opinion on this topic?
>
> Okay, trying to grok the question here. If the question is do we want to
> introduce a mutex/condition variable and lock/unlock signal/wait
> abstraction?
>
> I would certainly like to see reduced conditional compilation that
> applications have to perform for the platform features. I also really
> would like to purge the remaining pthread_{mutex,condvar} shim since it
> is unsightly.
>
> With msvc I think we could probably achieve the same with C11 threads but
> I haven't investigated feasability and said with no investigation older
> glibc may not provide the optional feature.
>
> In the absence of C11 threads we can provide an rte_ abstraction but I
> don't think I can put it on the roadmap until basic msvc support is
> stood up (a question of resource prioritization as always).
>
> I could commit to looking at it once msvc and atomics changes are merged
> the earliest possible time frame for that is the start of the 23.11
> cycle. If that happens at decent velocity I could even see adding it to
> 23.11 roadmap.

Ok for me.


>
> For now if someone else decides to introduce an abstraction I would just
> caution strongly not to remove __rte_experimental from any API added
> until I get a chance to focus on it.

We *could* introduce an internal API.
But I prefer we wait for your input on this topic rather than
introduce some artificial API.

I'll simply disable those checks on FreeBSD.


-- 
David Marchand