From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 75DD041B7B; Sat, 14 Oct 2023 01:32:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4532240276; Sat, 14 Oct 2023 01:32:02 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 7A7B040275 for ; Sat, 14 Oct 2023 01:32:01 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 482FB202CC; Sat, 14 Oct 2023 01:31:59 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v7 4/4] eal: add nonnull and access function attributes X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 14 Oct 2023 01:31:56 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EF4A@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D878EC@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v7 4/4] eal: add nonnull and access function attributes Thread-Index: Adk6UHl9qURHtgQyRNi9WHiS4zq8TBHVjiGgHyDugNA= References: <20221202153432.131023-1-mb@smartsharesystems.com> <3659208.MHq7AAxBmi@thomas> <98CBD80474FA8B44BF855DF32C47DC35D876E6@smartserver.smartshare.dk> <5353813.29KlJPOoH8@thomas> <98CBD80474FA8B44BF855DF32C47DC35D87704@smartserver.smartshare.dk> <20230206172842.GA16086@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D878EC@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "David Marchand" , "Thomas Monjalon" Cc: "Tyler Retzlaff" , , "Ferruh Yigit" , , , , , , , , , , , , , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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=3D26561 Med venlig hilsen / Kind regards, -Morten Br=F8rup > From: Morten Br=F8rup [mailto:mb@smartsharesystems.com] > Sent: Monday, 8 May 2023 14.33 >=20 > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Monday, 6 February 2023 18.29 > > > > On Mon, Feb 06, 2023 at 05:49:18PM +0100, Morten Br=F8rup wrote: > > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > > Sent: Monday, 6 February 2023 17.11 > > > > > > > > On Wed, Feb 1, 2023 at 2:16 PM Thomas Monjalon > > > > > wrote: >=20 > [...] >=20 > > > > > > 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. >=20 > David, Thomas, >=20 > FYI: >=20 > 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. >=20 > Stretch goal: I'm considering if these new attributes could somehow = also > support MSVC, but let's not discuss that now! >=20 > PS: The other patches in the series are independent of this patch, and > can be considered individually. >=20 > -Morten