[PATCH v4 1/9] eal: annotate spinlock, rwlock and seqlock

[Tyler Retzlaff]

On Thu, Jan 19, 2023 at 10:16:35PM +0100, David Marchand wrote:
> On Thu, Jan 19, 2023 at 9:39 PM Tyler Retzlaff
> <roretzla at linux.microsoft.com> wrote:
> >
> > On Thu, Jan 19, 2023 at 11:42:02AM -0800, Stephen Hemminger wrote:
> > > On Thu, 19 Jan 2023 19:46:12 +0100
> > > David Marchand <david.marchand at redhat.com> wrote:
> > >
> > > > +#ifndef __DOXYGEN__
> > > > +   __rte_exclusive_lock_function(&seqlock->lock)
> > > > +#endif
> > > >  {
> > >
> > > Would be cleaner any required ifdefs was in rte_lock_annotations
> > > rather than sprinkling the code
> >
> > we briefly touched on abstracting annotations in another thread. it
> > would be favorable if annotations were stashed behind macros that could
> > be expanded for more than just clang/internal/under doxygen to make
> > available opportunities to use other annotation dialects that may be
> > compatible.
> 
> I am open to abstractions.
> Do you have pointers for an equivalent functionnality in other
> compilers/tooling?

aye, reference documentation for SALv2 is here.
https://learn.microsoft.com/en-us/cpp/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=msvc-170

locking annotations are here.
https://learn.microsoft.com/en-us/cpp/code-quality/annotating-locking-behavior?view=msvc-170

but just to reiterate i'm not pushing any particular implementation, or
saying that SAL will ever be used. i think pragmatically all that would
be nice for now is not creating a direct dependency on any tool that
allow space for others in the future. if the burden to do that is too
much though let's just do what we can to get the benefits.

> 
> 
> --
> David Marchand