Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <email@example.com>
To: Matthew Wilcox <firstname.lastname@example.org>
Cc: Alan Stern <email@example.com>,
Dave Chinner <firstname.lastname@example.org>,
Eric Biggers <email@example.com>,
firstname.lastname@example.org, Akira Yokosawa <email@example.com>,
Andrea Parri <firstname.lastname@example.org>,
Boqun Feng <email@example.com>,
Daniel Lustig <firstname.lastname@example.org>,
"Darrick J . Wong" <email@example.com>,
David Howells <firstname.lastname@example.org>,
Jade Alglave <email@example.com>,
Luc Maranget <firstname.lastname@example.org>,
Nicholas Piggin <email@example.com>,
Peter Zijlstra <firstname.lastname@example.org>,
Will Deacon <email@example.com>
Subject: Re: [PATCH] tools/memory-model: document the "one-time init" pattern
Date: Mon, 20 Jul 2020 09:04:34 -0700 [thread overview]
Message-ID: <20200720160433.GQ9247@paulmck-ThinkPad-P72> (raw)
On Mon, Jul 20, 2020 at 04:39:11PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 20, 2020 at 10:52:11AM -0400, Alan Stern wrote:
> > On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> > > On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > > > This is one of the reasons that the LKMM documetnation is so damn
> > > > > difficult to read and understand: just understanding the vocabulary
> > > > > it uses requires a huge learning curve, and it's not defined
> > > > > anywhere. Understanding the syntax of examples requires a huge
> > > > > learning curve, because it's not defined anywhere.
> > > >
> > > > Have you seen tools/memory-model/Documentation/explanation.txt?
> > >
> > > <raises eyebrow>
> > >
> > > Well, yes. Several times. I look at it almost daily, but that
> > > doesn't mean it's approachable, easy to read or even -that I
> > > understand what large parts of it say-. IOWs, that's one of the
> > > problematic documents that I've been saying have a huge learning
> > > curve.
> > Can you be more specific? For example, exactly where does it start to
> > become unapproachable or difficult to read?
> > Don't forget that this document was meant to help mitigate the LKMM's
> > learning curve. If it isn't successful, I want to improve it.
> I can't speak for Dave, but the introduction to that documentation makes
> it clear to me that it's not the document I want to read.
> : This document describes the ideas underlying the LKMM. It is meant
> : for people who want to understand how the model was designed. It does
> : not go into the details of the code in the .bell and .cat files;
> : rather, it explains in English what the code expresses symbolically.
> I don't want to know how the model was designed. I want to write a
> device driver, or filesystem, or whatever.
> Honestly, even the term "release semantics" trips me up _every_ time.
> It's a barrier to understanding because I have to translate it into "Oh,
> he means it's like an unlock". Why can't you just say "unlock semantics"?
One way to think of it is "release" as in "release a lock".
But to answer your question:
1. The rest of the industry settled on "release" for that form
of atomics a very long time ago. Yes, we could insist on
Linux-kernel exceptionalism, but that doesn't seem consistent
with the large number of people coming into the kernel, even if
2. If we were to say "unlock" instead of "release", consistency
would demand that we also say "lock" instead of "acquire".
But "lock" is subtlely different than "acquire", and there is
a history of people requesting further divergence.
3. At least one architecture has started using GCC intrinsics
to implement atomics. I would expect more to follow. And
the GCC intrinsics say "_release".
4. More cynically (and I do not bleach my hair, so yes, I do have the
hair color for it), the Linux kernel community is sufficiently
creative in its (ab)use of whatever tools happen to be lying
around that any name will become misleading over time in any case.
next prev parent reply other threads:[~2020-07-20 16:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 4:44 Eric Biggers
2020-07-17 5:49 ` Sedat Dilek
2020-07-17 12:35 ` Matthew Wilcox
2020-07-17 14:26 ` Alan Stern
2020-07-17 17:47 ` Matthew Wilcox
2020-07-17 17:51 ` Alan Stern
2020-07-18 1:02 ` Eric Biggers
2020-07-27 12:51 ` Matthew Wilcox
2020-07-17 21:05 ` Darrick J. Wong
2020-07-18 0:44 ` Darrick J. Wong
2020-07-18 1:38 ` Eric Biggers
2020-07-18 2:13 ` Matthew Wilcox
2020-07-18 5:28 ` Eric Biggers
2020-07-18 14:35 ` Alan Stern
2020-07-20 2:07 ` Dave Chinner
2020-07-20 9:00 ` Peter Zijlstra
2020-07-27 15:17 ` Alan Stern
2020-07-27 15:28 ` Matthew Wilcox
2020-07-27 16:01 ` Paul E. McKenney
2020-07-27 16:31 ` Alan Stern
2020-07-27 16:59 ` Matthew Wilcox
2020-07-27 19:13 ` Alan Stern
2020-07-17 20:53 ` Darrick J. Wong
2020-07-18 0:58 ` Eric Biggers
2020-07-18 1:25 ` Alan Stern
2020-07-18 1:40 ` Matthew Wilcox
2020-07-18 2:00 ` Dave Chinner
2020-07-18 14:21 ` Alan Stern
2020-07-18 2:00 ` Eric Biggers
2020-07-18 1:42 ` Dave Chinner
2020-07-18 14:08 ` Alan Stern
2020-07-20 1:33 ` Dave Chinner
2020-07-20 14:52 ` Alan Stern
2020-07-20 15:37 ` Darrick J. Wong
2020-07-20 15:39 ` Matthew Wilcox
2020-07-20 16:04 ` Paul E. McKenney [this message]
2020-07-20 16:48 ` peterz
2020-07-20 22:06 ` Paul E. McKenney
2020-07-20 16:12 ` Alan Stern
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] tools/memory-model: document the "one-time init" pattern' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).