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

[Ingo Molnar <mingo@kernel.org>]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, Mar 18 2025 at 19:20, Ingo Molnar wrote:
> > * 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...
> 
> That's complete and utter nonsense.

I love you too! :-)

> 'we cancel the worker, we call kmalloc()' are purely colloquial 
> expressions.

So what? I have no problem with colloquial, familiar, everyday language 
in a technical context as long as it's effective and unambiguous.

The main linguistic advantage of German engineering is the ability to 
construct new, unambiguous words out of thin air:

   "Donaudampfschifffahrtselektrizitätenhauptbetriebswerkbauunternehmenbeamtengesellschaft"

... not the cold, impersonal tone. And I say that as a German, and yes, 
the 87-letter word above is a real, valid German word. :-)

> Liguistically they are factually wrong abominations.
> 
> We can cancel a subscription, an appointment, a booking... We can 
> call a taxi, a ambulance, a doctor, ....
> 
> But as a matter of fact, we _cannot_ cancel a worker or call 
> kmalloc().

Nor can we read a source buffer, nor can we do multiple writes to a 
destination buffer, right?

Tell that to Linus, who arguably writes one of the best changelogs in 
the kernel:

  # 9022ed0e7e65 ("strscpy: write destination buffer only once")

    In particular, the same way we shouldn't read the source buffer more
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    than once, we should avoid doing multiple writes to the destination
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    buffer: first writing a potentially non-terminated string, and then
    ^^^^^^^
    terminating it with NUL at the end does not result in a stable result
    buffer.

And I think the moment you have to argue against the quality of Linus's 
changelogs you've lost the argument really, almost by default.

> Changelogs as any other serious writing in technical context are about
> precision and clarity.

Absolutely, and 'we' in this context unambiguously means the kernel, so 
it's as clear to me as it gets.

I (obviously) agree with most of the stylistic and linguistic 
suggestions in Documentation/process/maintainer-tip.rst, and maybe my 
reaction was a bit hyperbolic (sorry), I just pointed out that this 
silly avoidance of pronouns like 'we' - which started the discussion - 
which results in *sentences with more words*, is *obviously* 
counterproductive.

Longer sentences with the same information content == worse.

To visualize it:

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

In communication shorter is better, if the information content is 
otherwise equivalent.

Anyway, let's agree to disagree. :-)

Thanks,

	Ingo