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:m...@smartsharesystems.com] > Sent: Monday, 8 May 2023 14.33 > > > From: Tyler Retzlaff [mailto:roret...@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.march...@redhat.com] > > > > Sent: Monday, 6 February 2023 17.11 > > > > > > > > On Wed, Feb 1, 2023 at 2:16 PM Thomas Monjalon > <tho...@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
