From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Xin Li <xin@zytor.com>,
linux-kernel@vger.kernel.org, Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
"Ahmed S . Darwish" <darwi@linutronix.de>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"H . Peter Anvin" <hpa@zytor.com>,
John Ogness <john.ogness@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>
Date: Tue, 18 Mar 2025 19:20:38 +0100 [thread overview]
Message-ID: <Z9m5doW6IBVth-Kz@gmail.com> (raw)
In-Reply-To: <20250318121557.GCZ9lj_UyOqr9Mkaag@fat_crate.local>
* Borislav Petkov <bp@alien8.de> wrote:
> On Tue, Mar 18, 2025 at 12:53:05PM +0100, Ingo Molnar wrote:
> > How is one more word and saying the same thing in a more circumspect
> > fashion a liguistic improvement?
>
> Because it removes the "we" out of the equation. I don't have to
> wonder who's the "we" the author is talking about: his employer, his
> private interests in Linux or "we" is actually "us" - the community
> as a whole.
In practice this is almost never ambiguous - and when it is, it can be
fixed up.
> I can't give a more honking example about the ambiguity here.
It's a red herring fallacy really. Let's go over the first example
given in Documentation/process/maintainer-tip.rst:
x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu
When a CPU is dying, we cancel the worker and schedule a new worker on a
different CPU on the same domain. But if the timer is already about to
expire (say 0.99s) then we essentially double the interval.
You'd have to be a bumbling idiot to think that the 'we' means an
employer or the person themselves ...
Put differently: *the very first example given* uses 'we' functionally
unambiguously so that everyone who can read kernel changelogs will
understand what it says. Ie. the whole policy is based on a false
statement...
Very few of the 'we' general pronouns used in kernel changelogs are
actually ambiguous. This means that any crusade to eliminate 'we' from
changelogs is not just pointless, but also a waste of resources - it's
a net negative. At least IMHO. ;-)
> > The second sentence, "When a CPU is dying, we cancel the worker
> > and schedule a new worker on a different CPU on the same domain,"
> > is easier to understand. It uses simpler language and a more
> > direct structure, making it clearer for the reader.
>
> I disagree with the LLM - it is yet another proof that AI won't
> replace humans - if anything it'll make them *think* more. Which is
> good! :-)
Yeah, and in any case, tastes differ, so no strong feelings from me
either! :-)
Thanks,
Ingo
next prev parent reply other threads:[~2025-03-18 18:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 22:18 [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up Ingo Molnar
2025-03-17 22:18 ` [PATCH 1/5] x86/cpuid: Refactor <asm/cpuid.h> Ingo Molnar
2025-03-18 12:00 ` [tip: x86/cpu] " tip-bot2 for Ahmed S. Darwish
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Ahmed S. Darwish
2025-03-17 22:18 ` [PATCH 2/5] x86/cpuid: Clean up <asm/cpuid/types.h> Ingo Molnar
2025-03-18 12:00 ` [tip: x86/cpu] " tip-bot2 for Ingo Molnar
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Ingo Molnar
2025-03-17 22:18 ` [PATCH 3/5] x86/cpuid: Clean up <asm/cpuid/api.h> Ingo Molnar
2025-03-18 12:00 ` [tip: x86/cpu] " tip-bot2 for Ingo Molnar
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Ingo Molnar
2025-03-17 22:18 ` [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h> Ingo Molnar
2025-03-18 5:59 ` Xin Li
2025-03-18 12:00 ` [tip: x86/cpu] " tip-bot2 for Ingo Molnar
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Ingo Molnar
2025-03-17 22:18 ` [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t " Ingo Molnar
2025-03-18 6:01 ` Xin Li
2025-03-18 8:34 ` Ingo Molnar
2025-03-18 9:37 ` Borislav Petkov
2025-03-18 11:53 ` Ingo Molnar
2025-03-18 12:15 ` Borislav Petkov
2025-03-18 18:20 ` Ingo Molnar [this message]
2025-03-19 8:08 ` Thomas Gleixner
2025-03-19 20:16 ` Ingo Molnar
2025-03-18 12:00 ` [tip: x86/cpu] " tip-bot2 for Ingo Molnar
2025-03-19 11:03 ` [tip: x86/core] " tip-bot2 for Ingo Molnar
2025-03-18 14:05 ` [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up H. Peter Anvin
2025-03-18 18:04 ` Ingo Molnar
2025-03-18 18:33 ` Linus Torvalds
2025-03-18 18:46 ` Ingo Molnar
2025-03-18 20:11 ` [PATCH] compiler/gcc: Make asm() templates asm __inline__() by default Ingo Molnar
2025-03-18 22:07 ` Josh Poimboeuf
2025-03-19 4:57 ` Uros Bizjak
2025-03-19 22:34 ` Ingo Molnar
2025-03-20 8:21 ` Uros Bizjak
2025-03-20 8:59 ` Ingo Molnar
2025-03-20 10:30 ` Uros Bizjak
2025-03-20 11:58 ` Uros Bizjak
2025-03-19 3:30 ` [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2025-03-17 22:30 mingo
2025-03-17 22:30 ` [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h> mingo
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=Z9m5doW6IBVth-Kz@gmail.com \
--to=mingo@kernel.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=darwi@linutronix.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=xin@zytor.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