Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar <mingo@kernel.org>]

* Borislav Petkov <bp@alien8.de> wrote:

> On Tue, Mar 18, 2025 at 09:34:41AM +0100, Ingo Molnar wrote:
> > That's a stupid rule, I don't know where it came from, and I never 
> > enforced it. It's not in Documentation/process/coding-style.rst.
> 
> I believe tglx came up with it - section "Changelog" in
> 
> Documentation/process/maintainer-tip.rst
> 
> Read the examples there.

Literally the first example there is kinda bogus:

  Example 1::

    ...

    When a CPU is dying, we cancel the worker and schedule a new worker 
    on a different CPU on the same domain.

  Improved version::

    ... 

    When a CPU is dying, the worker is canceled and a new worker is 
    scheduled on a different CPU in the same domain.

[ Note that I edited the first example to be a true equivalent 
  transformation to passive voice. The example in maintainer-tip.rst 
  makes other edits too which make it hard to compare. ]

How is one more word and saying the same thing in a more circumspect 
fashion a liguistic improvement?

And you don't have to believe me - I gave an LLM the following prompt:

  Which English sentence is easier to understand:
    "When a CPU is dying, the worker is canceled and a new worker is 
     scheduled on a different CPU in the same domain."
  or
    "When a CPU is dying, we cancel the worker and schedule a new worker 
     on a different CPU on the same domain."?

And it answered:

  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.

... and although I'd be the first one to distrust an LLM's opinion, 
it's correct in this case IMHO.

> And you and I have had this conversation already on IRC. I happen to 
> agree with him that "we" is ambiguous - with all those companies 
> submitting patches you don't know who's "we" interests are being 
> taken care of.

Few people will understand a generic personal pronoun to apply to a 
corporate entity magically, unless it's really clear and specific:

	"We at Intel believe that this condition cannot occur on Intel 
	 hardware."

in which case it's not a generic personal pronoun anymore.

Or to give another data point: since the v6.13 merge cycle we have 
merged over 11,000 commits in the upstream kernel, and over 1,500 
contain the word 'we' - over 13% of all commits. This is literally a 
pointless battle that creates unnecessary maintenance overhead and 
pointless detours for developers.

> And if you formulate your commit message in impersonal tone, it reads a lot
> clearer. It is simply a lot better this way.

Except *not even we* follow it consistently:

  starship:~/tip> gl --author=tglx --since=two-years-ago --grep='\<we\>' linus | grep -iw we
         by a context from task B and we do the check
    So it turns out that we have to do two passes of
      "The problem in current microcode loading method is that we load a
       microcode way, way too late; ideally we should load it before turning
       paging on.  This may only be practical on 32 bits since we can't get
       to 64-bit mode without paging on, but we should still do it as early
    MADT delivers we only trust the hardware anyway.
             * booting is too fragile that we want to limit the

Because it's actually a natural and direct linguistic construct.

And have a look at:

   $ gl --author=torvalds --since=two-years-ago --grep='\<we\>' linus | grep -iw we

it's 1352 examples of Linus using 'we' as a generic personal pronoun in 
the last 2 years alone...

Thanks,

	Ingo