linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>, Luo Jie <quic_luoj@quicinc.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Julia Lawall <Julia.Lawall@inria.fr>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	linux-kernel@vger.kernel.org, cocci@inria.fr,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	quic_kkumarcs@quicinc.com, quic_linchen@quicinc.com,
	quic_leiwei@quicinc.com, quic_suruchia@quicinc.com,
	quic_pavir@quicinc.com
Subject: Re: [PATCH v3 0/6] Add FIELD_MODIFY() helper
Date: Fri, 18 Apr 2025 13:04:28 -0400	[thread overview]
Message-ID: <aAKGHIssRW5jXvdA@yury> (raw)
In-Reply-To: <87plh9xz2d.wl-maz@kernel.org>

On Fri, Apr 18, 2025 at 04:35:22PM +0100, Marc Zyngier wrote:
> On Fri, 18 Apr 2025 16:08:38 +0100,
> Yury Norov <yury.norov@gmail.com> wrote:
> > 
> > On Thu, Apr 17, 2025 at 06:45:12PM +0100, Marc Zyngier wrote:
> > > On Thu, 17 Apr 2025 18:22:29 +0100,
> > > Andrew Lunn <andrew@lunn.ch> wrote:
> > > > 
> > > > On Thu, Apr 17, 2025 at 12:10:54PM +0100, Marc Zyngier wrote:
> > > > > On Thu, 17 Apr 2025 11:47:07 +0100,
> > > > > Luo Jie <quic_luoj@quicinc.com> wrote:
> > > > > > 
> > > > > > Add the helper FIELD_MODIFY() to the FIELD_XXX family of bitfield
> > > > > > macros. It is functionally similar as xxx_replace_bits(), but adds
> > > > > > the compile time checking to catch incorrect parameter type errors.
> > > > > > 
> > > > > > This series also converts the four instances of opencoded FIELD_MODIFY()
> > > > > > that are found in the core kernel files, to instead use the new
> > > > > > FIELD_MODIFY() macro. This is achieved with Coccinelle, by adding
> > > > > > the script field_modify.cocci.
> > > > > > 
> > > > > > The changes are validated on IPQ9574 SoC which uses ARM64 architecture.
> > > > > 
> > > > > We already have the *_replace_bits() functions (see
> > > > > include/linux/bitfield.h).
> > > > > 
> > > > > Why do we need extra helpers?
> > > > 
> > > > If you look at bitfield.h, the *_replace_bits() seem to be
> > > > undocumented internal macro magic, not something you are expected to
> > > > use. What you are expected to use in that file is however well
> > > > documented. The macro magic also means that cross referencing tools
> > > > don't find them.
> > > 
> > > $ git grep _replace_bits|  wc -l
> > > 1514
> > 
> > FIELD_PREP() only is used 10 times more.
> 
> And? I'm sure that if you count "+", you'll find it to be yet a few
> order of magnitudes more.

And nothing. It seems that you like statistics, so I shared some more.

> > > I think a bunch of people have found them, tooling notwithstanding.
> > > 
> > > As for the documentation, the commit message in 00b0c9b82663ac would
> > > be advantageously promoted to full-fledged kernel-doc.
> > 
> > The FIELD_MODIFY() and uxx_replace_bits() are simply different things.
> > 
> > FIELD_MODIFY() employs __BF_FIELD_CHECK(), which allows strict
> > parameters checking at compile time. And people like it. See
> > recent fixed-size GENMASK() series:
> > 
> > https://patchwork.kernel.org/comment/26283604/
> 
> I don't care much for what people like or not. I don't see this
> FIELD_MODIFY() as a particular improvement on *_replace_bits().

Sad to hear that. Those people are all kernel engineers, and they
deserve some respect.

We are talking about tooling here. People use tools only if they like
them. Luo likes FIELD_MODIFY() over (yes, undocumented and ungreppable)
xx_replace_bits() for the reasons he described very clearly. He's going
to use it in his driver shortly, and this arm64 detour has been made
after my request.

From my perspective, both functions have their right to live in kernel.
They are similar but not identical.

I'll take patch #1 in my branch. Regarding ARM64 part - it's up to you
either to switch to FIELD_MODIFY(), _replace_bits(), or do nothing.

Thanks,
Yury


  reply	other threads:[~2025-04-18 17:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 10:47 [PATCH v3 0/6] Add FIELD_MODIFY() helper Luo Jie
2025-04-17 10:47 ` [PATCH v3 1/6] bitfield: " Luo Jie
2025-04-18 17:11   ` Yury Norov
2025-04-23 13:05     ` Jie Luo
2025-04-17 10:47 ` [PATCH v3 2/6] coccinelle: misc: Add field_modify script Luo Jie
2025-04-23 11:01   ` [cocci] " Markus Elfring
2025-04-23 13:04     ` Jie Luo
2025-04-23 16:35       ` Markus Elfring
2025-05-19 13:44         ` Luo Jie
2025-05-19 15:39           ` Julia Lawall
2025-04-17 10:47 ` [PATCH v3 3/6] arm64: tlb: Convert the opencoded field modify Luo Jie
2025-04-17 18:11   ` Russell King (Oracle)
2025-04-23 13:15     ` Jie Luo
2025-04-24 15:24       ` [cocci] " Keller, Jacob E
2025-04-23 16:54     ` Keller, Jacob E
2025-04-17 10:47 ` [PATCH v3 4/6] arm64: nvhe: " Luo Jie
2025-04-17 11:23   ` Marc Zyngier
2025-04-18 15:14     ` Yury Norov
2025-04-18 15:34       ` Marc Zyngier
2025-04-23 17:48       ` Russell King (Oracle)
2025-04-23 18:27         ` Yury Norov
2025-04-23 19:11           ` Russell King (Oracle)
2025-04-23 19:40             ` Yury Norov
2025-04-17 10:47 ` [PATCH v3 5/6] arm64: kvm: " Luo Jie
2025-04-17 10:47 ` [PATCH v3 6/6] arm64: mm: " Luo Jie
2025-04-17 11:10 ` [PATCH v3 0/6] Add FIELD_MODIFY() helper Marc Zyngier
2025-04-17 17:22   ` Andrew Lunn
2025-04-17 17:45     ` Marc Zyngier
2025-04-18 15:08       ` Yury Norov
2025-04-18 15:35         ` Marc Zyngier
2025-04-18 17:04           ` Yury Norov [this message]
2025-04-23 13:19             ` Jie Luo
2025-04-23 17:44         ` Russell King (Oracle)
2025-04-23 18:44           ` Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAKGHIssRW5jXvdA@yury \
    --to=yury.norov@gmail.com \
    --cc=Julia.Lawall@inria.fr \
    --cc=andrew@lunn.ch \
    --cc=catalin.marinas@arm.com \
    --cc=cocci@inria.fr \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=maz@kernel.org \
    --cc=nicolas.palix@imag.fr \
    --cc=oliver.upton@linux.dev \
    --cc=quic_kkumarcs@quicinc.com \
    --cc=quic_leiwei@quicinc.com \
    --cc=quic_linchen@quicinc.com \
    --cc=quic_luoj@quicinc.com \
    --cc=quic_pavir@quicinc.com \
    --cc=quic_suruchia@quicinc.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).