Message-ID: <Z_a9YpE46Xf8581l@yury>
Date: Wed, 9 Apr 2025 14:33:06 -0400
From: Yury Norov <yury.norov@...il.com>
To: Kuan-Wei Chiu <visitorckw@...il.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, jk@...abs.org,
	joel@....id.au, eajames@...ux.ibm.com, andrzej.hajda@...el.com,
	neil.armstrong@...aro.org, rfoss@...nel.org,
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
	tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
	dmitry.torokhov@...il.com, mchehab@...nel.org,
	awalls@...metrocast.net, hverkuil@...all.nl,
	miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
	louis.peens@...igine.com, andrew+netdev@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	parthiban.veerasooran@...rochip.com, arend.vanspriel@...adcom.com,
	johannes@...solutions.net, gregkh@...uxfoundation.org,
	jirislaby@...nel.org, akpm@...ux-foundation.org, jdelvare@...e.com,
	linux@...ck-us.net, alexandre.belloni@...tlin.com, pgaj@...ence.com,
	hpa@...or.com, alistair@...ple.id.au, linux@...musvillemoes.dk,
	Laurent.pinchart@...asonboard.com, jonas@...boo.se,
	jernej.skrabec@...il.com, kuba@...nel.org,
	linux-kernel@...r.kernel.org, linux-fsi@...ts.ozlabs.org,
	dri-devel@...ts.freedesktop.org, linux-input@...r.kernel.org,
	linux-media@...r.kernel.org, linux-mtd@...ts.infradead.org,
	oss-drivers@...igine.com, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org, brcm80211@...ts.linux.dev,
	brcm80211-dev-list.pdl@...adcom.com, linux-serial@...r.kernel.org,
	bpf@...r.kernel.org, jserv@...s.ncku.edu.tw, Frank.Li@....com,
	linux-hwmon@...r.kernel.org, linux-i3c@...ts.infradead.org,
	david.laight.linux@...il.com, andrew.cooper3@...rix.com,
	Yu-Chun Lin <eleanor15x@...il.com>
Subject: Re: [PATCH v4 00/13] Introduce parity_odd() and refactor redundant
 parity code

On Thu, Apr 10, 2025 at 02:15:30AM +0800, Kuan-Wei Chiu wrote:
> On Wed, Apr 09, 2025 at 12:54:35PM -0400, Yury Norov wrote:
> > On Wed, Apr 09, 2025 at 11:43:43PM +0800, Kuan-Wei Chiu wrote:
> > > Several parts of the kernel contain open-coded and redundant
> > > implementations of parity calculation. This patch series introduces
> > > a unified helper, parity_odd(), to simplify and standardize these
> > > cases.
> > > 
> > > The first patch renames parity8() to parity_odd(), changes its argument
> > 
> > Alright, if it's an extension of the area of applicability, it should be
> > renamed to just parity(). I already shared a table that summarized the
> > drivers authors' view on that, and they clearly prefer not to add the
> > suffix - 13 vs 2. The __builtin_parity() doesn't care of suffix as well. 
> > 
> > https://lore.kernel.org/all/Z9GtcNJie8TRKywZ@thinkpad/
> > 
> > Yes, the argument that boolean function should explain itself sounds
> > correct, but in this case, comment on top of the function looks enough
> > to me.
> > 
> > The existing codebase doesn't care about the suffix as well. If no
> > strong preference, let's just pick a short and sweet name?
> > 
> I don't have a strong preference for the name, but if I had to guess
> the return value from the function prototype, I would intuitively
> expect an int to return "0 for even and 1 for odd," and a bool to
> return "true for even, false for odd." I recall Jiri and Jacob shared
> similar thoughts, which is why I felt adding _odd could provide better
> clarity.

I think they said they are convinced that parity should return 1 for
odd because of folding and __builtin_parity() arguments.
 
> However, I agree that if the kernel doc comment is clear, it might not
> be a big issue. But David previously mentioned that he doesn't want to
> rely on checking the function's documentation every time while reading
> the code.

He's wrong. Kernel engineers _must_ read documentation, regardless.
 
> Regardless, I'm flexible as long as we all reach a consensus on the
> naming.
> 
> > > type from u8 to u64 for broader applicability, and updates its return
> > > type from int to bool to make its usage and return semantics more
> > > intuitive-returning true for odd parity and false for even parity. It
> > > also adds __attribute_const__ to enable compiler optimizations.
> > 
> > That's correct and nice, but can you support it with a bloat-o-meter's
> > before/after and/or asm snippets? I also think it worth to be a separate
> > patch, preferably the last patch in the series.
> > 
> I quickly tested it with the x86 defconfig, and it appears that the
> generated code doesn't change. I forgot who requested the addition
> during the review process, but I initially thought it would either
> improve the generated code or leave it unchanged without significantly
> increasing the source code size.

That's what I actually expected, but was shy to guess openly. :). It's
hard to imagine how compiler may improve code generation in this case...

This attribute is used when there's an asm block, or some non-trivial
function call. In this case, the function is self-consistent and makes
no calls. And you see, const annotation raises more questions than
solves problems. Let's drop it.

Thanks,
Yury

Powered by blists - more mailing lists