> 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
