mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org, akiyks@gmail.com,
	linux-doc@vger.kernel.org, kernel-team@meta.com,
	Will Deacon <will@kernel.org>, Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [PATCH locking/atomic 18/19] locking/atomic: Refrain from generating duplicate fallback kernel-doc
Date: Thu, 11 May 2023 22:46:33 +0200	[thread overview]
Message-ID: <20230511204633.GF2296992@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <613a2d06-30f1-4140-aa6c-16d5298d9909@paulmck-laptop>

On Thu, May 11, 2023 at 01:25:18PM -0700, Paul E. McKenney wrote:
> On Thu, May 11, 2023 at 10:01:42PM +0200, Peter Zijlstra wrote:
> > On Thu, May 11, 2023 at 12:53:46PM -0700, Paul E. McKenney wrote:
> > > Do you have an alternative suggestion for generating the kernel-doc?
> > > The current lack of it is problematic.
> > 
> > I've never found a lack of kernel-doc to be a problem. And I'm very much
> > against complicating the scripts to add it.
> 
> I am sure that you have not recently found the lack of kernel-doc for
> the atomic operations to be a problem, given that you wrote many of
> these functions.

Sure; but I meant in general -- I've *never* used kernel-doc. Comments I
occasionally read, and sometimes they're not even broken either, but
kernel-doc, nope.

> OK, you mentioned concerns about documentation people nitpicking.  This
> can be dealt with.  The added scripting is not that large or complex.
> 
> > Also, there's Documentation/atomic_t.txt
> 
> Yes, if you very carefully read that document end to end, correctly
> interpreting it all, you will know what you need to.  Of course, first
> you have to find it.  And then you must avoid any lapses while reading
> it while under pressure.  Not particularly friendly to someone trying
> to chase a bug.

It's either brief and terse or tediously long -- I vastly prefer the
former, my brain can much better parse structure than English prose.

Also, I find, pressure is never conductive to anything, except prehaps
cooking rice and steam trains (because nothing is as delicous as a
pressure cooked train -- oh wait).

Add enough pressure and the human brain reduces to driven and can't read
even the most coherent of text no matter how easy to find.

In such situations it's for the manager to take the pressure away and
the engineer to think in relative peace.

  reply	other threads:[~2023-05-11 20:46 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10 18:15 [PATCH locking/atomics 0/19] Add kernel-doc for more atomic operations Paul E. McKenney
2023-05-10 18:16 ` [PATCH locking/atomic 01/19] locking/atomic: Fix fetch_add_unless missing-period typo Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 02/19] locking/atomic: Add "@" before "true" and "false" for fallback templates Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 03/19] locking/atomic: Add kernel-doc and docbook_oldnew variables for headers Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 04/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}inc${sfx}${order} Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 05/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}dec${sfx}${order} Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 06/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}andnot${sfx}${order} Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 07/19] locking/atomic: Add kernel-doc header for arch_${atomic}_try_cmpxchg${order} Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 08/19] locking/atomic: Add kernel-doc header for arch_${atomic}_dec_if_positive Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 09/19] locking/atomic: Add kernel-doc header for arch_${atomic}_dec_unless_positive Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 10/19] locking/atomic: Add kernel-doc header for arch_${atomic}_inc_unless_negative Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 11/19] locking/atomic: Add kernel-doc header for arch_${atomic}_set_release Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 12/19] locking/atomic: Add kernel-doc header for arch_${atomic}_read_acquire Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 13/19] locking/atomic: Script to auto-generate acquire, fence, and release headers Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 14/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}${name}${sfx}_acquire Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 15/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}${name}${sfx}_release Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 16/19] locking/atomic: Add kernel-doc header for arch_${atomic}_${pfx}${name}${sfx} Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 17/19] x86/atomic.h: Remove duplicate kernel-doc headers Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 18/19] locking/atomic: Refrain from generating duplicate fallback kernel-doc Paul E. McKenney
2023-05-11 17:10   ` Mark Rutland
2023-05-11 19:12     ` Paul E. McKenney
2023-05-12 13:18       ` Mark Rutland
2023-05-12 16:01         ` Paul E. McKenney
2023-05-12 17:03           ` Mark Rutland
2023-05-12 18:42             ` Paul E. McKenney
2023-05-13  2:11               ` Paul E. McKenney
2023-05-13 23:58                 ` Akira Yokosawa
2023-05-14  1:14                   ` Paul E. McKenney
2023-05-16 16:52                     ` Mark Rutland
2023-05-16 18:42                       ` Paul E. McKenney
2023-05-11 19:38     ` Peter Zijlstra
2023-05-11 19:53       ` Paul E. McKenney
2023-05-11 20:01         ` Peter Zijlstra
2023-05-11 20:25           ` Paul E. McKenney
2023-05-11 20:46             ` Peter Zijlstra [this message]
2023-05-11 20:48               ` Peter Zijlstra
2023-05-11 21:24                 ` Paul E. McKenney
2023-05-12 13:30       ` Mark Rutland
2023-05-11 20:18   ` Peter Zijlstra
2023-05-11 20:29     ` Paul E. McKenney
2023-05-10 18:17 ` [PATCH locking/atomic 19/19] docs: Add atomic operations to the driver basic API documentation Paul E. McKenney
2023-05-16 21:33   ` Kees Cook
2023-05-17 10:10     ` Paul E. McKenney
2023-05-22 12:30       ` Mark Rutland

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=20230511204633.GF2296992@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=paulmck@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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

Powered by JetHome