From: tip-bot for Peter Zijlstra <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
peterz@infradead.org, tglx@linutronix.de,
torvalds@linux-foundation.org, paulmck@linux.vnet.ibm.com
Subject: [tip:locking/core] locking/Documentation: Add disclaimer
Date: Thu, 28 Apr 2016 03:27:58 -0700 [thread overview]
Message-ID: <tip-e7720af5f9ac914577e2b810d5c004cdf395fd82@git.kernel.org> (raw)
In-Reply-To: <1461691328-5429-1-git-send-email-paulmck@linux.vnet.ibm.com>
Commit-ID: e7720af5f9ac914577e2b810d5c004cdf395fd82
Gitweb: http://git.kernel.org/tip/e7720af5f9ac914577e2b810d5c004cdf395fd82
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Tue, 26 Apr 2016 10:22:05 -0700
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 28 Apr 2016 10:57:51 +0200
locking/Documentation: Add disclaimer
It appears people are reading this document as a requirements list for
building hardware. This is not the intent of this document. Nor is it
particularly suited for this purpose.
The primary purpose of this document is our collective attempt to define
a set of primitives that (hopefully) allow us to write correct code on
the myriad of SMP platforms Linux supports.
Its a definite work in progress as our understanding of these platforms,
and memory ordering in general, progresses.
Nor does being mentioned in this document mean we think its a
particularly good idea; the data dependency barrier required by Alpha
being a prime example. Yes we have it, no you're insane to require it
when building new hardware.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: corbet@lwn.net
Cc: dave@stgolabs.net
Cc: dhowells@redhat.com
Cc: linux-doc@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1461691328-5429-1-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
Documentation/memory-barriers.txt | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a9454b1..fb2dd35 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -4,8 +4,24 @@
By: David Howells <dhowells@redhat.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+ Will Deacon <will.deacon@arm.com>
+ Peter Zijlstra <peterz@infradead.org>
-Contents:
+==========
+DISCLAIMER
+==========
+
+This document is not a specification; it is intentionally (for the sake of
+brevity) and unintentionally (due to being human) incomplete. This document is
+meant as a guide to using the various memory barriers provided by Linux, but
+in case of any doubt (and there are many) please ask.
+
+To repeat, this document is not a specification of what Linux expects from
+hardware.
+
+========
+CONTENTS
+========
(*) Abstract memory access model.
next prev parent reply other threads:[~2016-04-28 10:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 17:20 [PATCH locking 0/4] locktorture and memory-barriers.txt updates Paul E. McKenney
2016-04-26 17:22 ` [PATCH locking 1/4] documentation: Add disclaimer Paul E. McKenney
2016-04-28 10:27 ` tip-bot for Peter Zijlstra [this message]
2016-04-26 17:22 ` [PATCH locking 2/4] documentation: State purpose of memory-barriers.txt Paul E. McKenney
2016-04-28 10:28 ` [tip:locking/core] locking/Documentation: " tip-bot for David Howells
2016-04-26 17:22 ` [PATCH locking 3/4] documentation: ACQUIRE applies to loads, RELEASE applies to stores Paul E. McKenney
2016-04-28 10:28 ` [tip:locking/core] locking/Documentation: Clarify that " tip-bot for Will Deacon
2016-04-26 17:22 ` [PATCH locking 4/4] locktorture: Simplify torture_runnable computation Paul E. McKenney
2016-04-28 10:29 ` [tip:locking/core] lcoking/locktorture: Simplify the " tip-bot for 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=tip-e7720af5f9ac914577e2b810d5c004cdf395fd82@git.kernel.org \
--to=tipbot@zytor.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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