mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Peter Zijlstra <peterz@infradead.org>,
	parri.andrea@gmail.com, will.deacon@arm.com,
	boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com,
	j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
	linux-kernel@vger.kernel.org, elena.reshetova@intel.com
Subject: Re: Prototype patch for Linux-kernel memory model
Date: Tue, 14 Nov 2017 09:15:05 -0800	[thread overview]
Message-ID: <20171114171505.GS3624@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1711141016340.1796-100000@iolanthe.rowland.org>

On Tue, Nov 14, 2017 at 10:19:21AM -0500, Alan Stern wrote:
> On Tue, 14 Nov 2017, Peter Zijlstra wrote:
> 
> > On Mon, Nov 13, 2017 at 10:40:31AM -0800, Paul E. McKenney wrote:
> > > commit 82a1431549b4eae531e83298fd72cd0acea08540
> > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > Date:   Mon Nov 13 10:30:07 2017 -0800
> > > 
> > >     tools: Automate memory-barriers.txt; provide Linux-kernel memory model
> > >     
> > >     There is some reason to believe that Documentation/memory-barriers.txt
> > >     could use some help, and a major purpose of this patch is to provide
> > >     that help in the form of a design-time tool that can produce all valid
> > >     executions of a small fragment of concurrent Linux-kernel code, which is
> > >     called a "litmus test".  This tool's functionality is roughly similar to
> > >     a full state-space search.  Please note that this is a design-time tool,
> > >     not useful for regression testing.  However, we hope that the underlying
> > >     Linux-kernel memory model will be incorporated into other tools capable
> > >     of analyzing large bodies of code for regression-testing purposes.
> > >     
> > >     The main tool is herd7, together with the linux-kernel.bell,
> > >     linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and lock.cat files
> > >     added by this patch.  The herd7 executable takes the other files as input,
> > >     and all of these files collectively define the Linux-kernel memory memory
> > >     model.  A brief description of each of these other files is provided
> > >     in the README file.  Although this tool does have its limitations,
> > >     which are documented in the README file, it does improve on the version
> > >     reported on in the LWN series (https://lwn.net/Articles/718628/ and
> > >     https://lwn.net/Articles/720550/) by supporting locking and arithmetic,
> > >     including a much wider variety of read-modify-write atomic operations.
> > >     Please note that herd7 is not part of this submission, but is freely
> > >     available from http://diy.inria.fr/sources/index.html (and via "git"
> > >     at https://github.com/herd/herdtools7).
> > >     
> > >     A second tool is klitmus7, which converts litmus tests to loadable
> > >     kernel modules for direct testing.  As with herd7, the klitmus7
> > >     code is freely available from http://diy.inria.fr/sources/index.html
> > >     (and via "git" at https://github.com/herd/herdtools7).
> > >     
> > >     Of course, litmus tests are not always the best way to fully understand a
> > >     memory model, so this patch also includes Documentation/explanation.txt,
> > >     which describes the memory model in detail.  In addition,
> > >     Documentation/recipes.txt provides example known-good and known-bad use
> > >     cases for those who prefer working by example.
> > >     
> > >     This patch also includes a few sample litmus tests, and a great many
> > >     more litmus tests are available at https://github.com/paulmckrcu/litmus.
> > >     
> > >     Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > >     Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
> > >     Signed-off-by: Will Deacon <will.deacon@arm.com>
> > >     Signed-off-by: Peter Zijlstra <peterz@infradead.org>
> > >     Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > >     Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > >     Signed-off-by: David Howells <dhowells@redhat.com>
> > >     Signed-off-by: Jade Alglave <j.alglave@ucl.ac.uk>
> > >     Signed-off-by: Luc Maranget <luc.maranget@inria.fr>
> > >     Signed-off-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > >     Cc: <linux-arch@vger.kernel.org>
> > 
> > So I think that SoB chains like that are utter crap. I think you meant
> > to have all but the one from you be an Ack or similar.
> 
> That's right.  Git doesn't understand the concept of multiple
> authorship.  Accepted practice is to have one Signed-off-by line and a
> bunch of Acked-by or Reviewed-by tags.
> 
> When there's a chain of Signed-off-by tags, it means the first person 
> was the author, who submitted it to the second person's tree, and it 
> went from there to the third person's tree, etc. (which would imply 
> multiple levels of maintainers and submaintainers).

I could add a paragraph just before the Signed-off-by/Acked-by/etc.
block describing the roles and contributions, convert the people who
were directly involved to Reviewed-by and everyone else to Acked-by
(unless they explicitly provided a Reviewed-by).

Would that work, or does someone have a better approach?

							Thanx, Paul

  reply	other threads:[~2017-11-14 17:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 18:40 Paul E. McKenney
2017-11-13 20:09 ` Alan Stern
2017-11-14  4:52   ` Paul E. McKenney
2017-11-14  7:59 ` Peter Zijlstra
2017-11-14 15:19   ` Alan Stern
2017-11-14 17:15     ` Paul E. McKenney [this message]
2017-11-15 16:37       ` Paul E. McKenney
2017-11-17 11:27         ` Boqun Feng
2017-11-20 16:35           ` Andrea Parri
2017-11-20 19:30             ` Paul E. McKenney
2017-12-19  8:36         ` afzal mohammed
2017-12-19 16:05           ` Alan Stern
2017-12-20 11:31         ` afzal mohammed
2017-12-20 16:45           ` Paul E. McKenney
2017-12-21  3:30             ` afzal mohammed
2017-12-21 16:15               ` Paul E. McKenney
2017-12-22  4:11                 ` afzal mohammed
2017-12-23  6:14                   ` afzal mohammed
2018-01-02 20:25                     ` Paul E. McKenney

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=20171114171505.GS3624@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=elena.reshetova@intel.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.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

Powered by JetHome