[PATCH v7 4/4] eal: add nonnull and access function attributes

[Morten Brørup]

David,

As mentioned below, the first 3 patches in this series [26561] can be considered as individual driver patches.

I guess this request was somehow missed. Should I delegate these 3 patches to the respective maintainers for the net-next-xxx trees in Patchwork, or how should I proceed?

Patches 1 and 2 are still valid as is (compared to the main branch). Patch 3 is a one-line modification where the modified line has moved further down.

[26561]: https://patchwork.dpdk.org/project/dpdk/list/?series=26561

Med venlig hilsen / Kind regards,
-Morten Brørup

> From: Morten Brørup [mailto:mb at smartsharesystems.com]
> Sent: Monday, 8 May 2023 14.33
> 
> > From: Tyler Retzlaff [mailto:roretzla at linux.microsoft.com]
> > Sent: Monday, 6 February 2023 18.29
> >
> > On Mon, Feb 06, 2023 at 05:49:18PM +0100, Morten Brørup wrote:
> > > > From: David Marchand [mailto:david.marchand at redhat.com]
> > > > Sent: Monday, 6 February 2023 17.11
> > > >
> > > > On Wed, Feb 1, 2023 at 2:16 PM Thomas Monjalon
> <thomas at monjalon.net>
> > > > wrote:
> 
> [...]
> 
> > >
> > > I'm leaning towards following the existing convention in
> rte_common.h, and
> > embrace Thomas' argument to make them more verbose in order to reduce
> the risk
> > of wrong use. In other words, define these:
> > >
> > > __rte_nonnull(...)
> > > __rte_read_only(ptr_index)
> > > __rte_read_only_size(ptr_index, size_index)
> > > __rte_write_only(ptr_index)
> > > __rte_write_only_size(ptr_index, size_index)
> > > __rte_read_write(ptr_index)
> > > __rte_read_write_size(ptr_index, size_index)
> > > __rte_no_access(ptr_index)
> > > __rte_no_access_size(ptr_index, size_index)
> > >
> > > >
> > > >
> > > > As for the lock annotations series, if you are not confident with
> the
> > > > form I went with, I don't mind deferring to a later release.
> > >
> > > The form follows the existing convention in rte_common.h, and I
> think we
> > should stick with it.
> > >
> > > > Though it adds more work on my pile like rebasing the vhost
> library.
> > > > Additionnally, we lose the opportunity to catch introduction of
> new
> > > > lock issues in the dpdk tree.
> > >
> > > Conclusion:
> > >
> > > The names I listed in this email, and what David already has in his
> lock
> > annotation patch, are both in line with an existing convention already
> > established in rte_common.h. So unless someone objects very soon,
> let's go for
> > that.
> 
> David, Thomas,
> 
> FYI:
> 
> I am deferring a new version this patch until a later DPDK release, so
> it doesn't get too much in the way of Tyler's MSVC patches.
> 
> Stretch goal: I'm considering if these new attributes could somehow also
> support MSVC, but let's not discuss that now!
> 
> PS: The other patches in the series are independent of this patch, and
> can be considered individually.
> 
> -Morten