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 D581045B04; Thu, 10 Oct 2024 15:08:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 73501402EA; Thu, 10 Oct 2024 15:08:00 +0200 (CEST) Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by mails.dpdk.org (Postfix) with ESMTP id 5063D402E8 for ; Thu, 10 Oct 2024 15:07:58 +0200 (CEST) Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id C56331380240; Thu, 10 Oct 2024 09:07:57 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Thu, 10 Oct 2024 09:07:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1728565677; x=1728652077; bh=JhdnU1FMkdGz4isEb7zZeKs7Gj+st1vdaEhHPJ5BryM=; b= QEIe8ChuLvJPmiZyxmjk0I2BLKlJNdI/etAwMfYuCtTDJvETh6kY4R3THabCBpje SvM4yzb3ObNtFJYzpHNR6yfPxySjFXe0LMVBwoNDbhWF6MbOI4rdt96xGYMbph7T GOgzHg6YdEZOQO9cgfcPfd5M7qrIVT4SjlhVyqWj/c2vpBb5UxfV6L7LR9IynVR1 o3HkZ9DxaFG2KHfot/ZxQHmAbUq+BAOLzw68Q5DOaTGcI8RVuRXGi4J6I8v12dUa uvsNsak8HA5txvm/ekm+hw9E5bDwCy1uS7KJGmZS7Ftiy1bRrn9Ytm4syfvJDnW5 QbuLJJZkGiFbk3OmDuG8wQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1728565677; x= 1728652077; bh=JhdnU1FMkdGz4isEb7zZeKs7Gj+st1vdaEhHPJ5BryM=; b=R FkpIpPdFdH93QQliEzyXatiXnZ28aYA6j6XtgcxaMXX+JuHrWuxtTd7YmCCJo/ed fr/jIM8LmuaMg189WQJvVVwo6jvklAzZQkAj0U10nImcWZXUXyDHHjwoB+JHNwxu MV/Tzz2ydFqohoAS007faeIQdpFpQNee5FWCeUf1Xz4ju0KAH1qA603G8v4vtr7S SvvDrnaJHjQNsXw1/rWCWBDkeCwxPAl7sGmz+Ggs9K7XrKyryUrlY8i4TSHpJEb9 8h1gyoinMM70TJs+XDgsaCHCQP8jzGLQOhSv/t6CbdscNpQ8jeEjY1u0dNbWR9lE Tsp0iZXRx7hlt7YEGKOew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdefhedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedt heevtdekiedvueeuvdeiuddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhn sggprhgtphhtthhopeduuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgrth htihgrshdrrhhonhhnsghlohhmsegvrhhitghsshhonhdrtghomhdprhgtphhtthhopehh ohhfohhrsheslhihshgrthhorhdrlhhiuhdrshgvpdhrtghpthhtohepuggrvhhiugdrmh grrhgthhgrnhgusehrvgguhhgrthdrtghomhdprhgtphhtthhopeguvghvseguphgukhdr ohhrghdprhgtphhtthhopehhvghnghdrfigrnhhgsegvrhhitghsshhonhdrtghomhdprh gtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrhdrohhrghdprhgt phhtthhopehrohhrvghtiihlrgeslhhinhhugidrmhhitghrohhsohhfthdrtghomhdprh gtphhtthhopehmsgesshhmrghrthhshhgrrhgvshihshhtvghmshdrtghomhdprhgtphht thhopehjrggtkhdrsghonhguqdhprhgvshhtohhnsehfohhsshdrrghrmhdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Oct 2024 09:07:55 -0400 (EDT) From: Thomas Monjalon To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: David Marchand , dev@dpdk.org, dev@dpdk.org, Heng Wang , Stephen Hemminger , Tyler Retzlaff , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Jack Bond-Preston , Chengwen Feng Subject: Re: [PATCH v12 6/7] eal: add unit tests for atomic bit access functions Date: Thu, 10 Oct 2024 15:07:53 +0200 Message-ID: <2203106.bB369e8A3T@thomas> In-Reply-To: References: <20240920062437.738706-2-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 10/10/2024 14:35, Mattias R=C3=B6nnblom: > On 2024-10-10 14:14, David Marchand wrote: > > On Thu, Oct 10, 2024 at 1:56=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > Your argument above makes sense, but I also find the kernel style more=20 > visually appealing. >=20 > >=20 > > In the end, I was left with cases like: > > \ > > \ > > \ > >=20 > > And I preferred to remove this extra line as it did not enhance the > > clarity of those macros. > >=20 > >=20 >=20 > \ > \ > \ >=20 > Would have been visually more appealing, but less consistent. >=20 > To me, removing these delimiting empty lines is no different from doing=20 > the same in a regular C function. Empty lines are delimiters, there to=20 > group related statements, and they serve a purpose. Now, the macros look= =20 > like they are written by someone who doesn't care about readability. Coding style discussions may become endless. At the end, the maintainers have to decide. In this case, the problem is having complex macros. That's why we tend to forbid macros when possible. I understand your frustration that your commit does not show how you wanted= it to appear. Please understand that David did his best to make it easy to maintain, cons= istent, and - the most important - merged in -rc1, given the limited time we all ha= ve. Nothing is perfect, but we all try our best. Thanks