summaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2016-04-26 10:22:06 -0700
committerIngo Molnar <mingo@kernel.org>2016-04-28 10:57:51 +0200
commit8d4840e84871847ee1bae56a776907d08a9265f7 (patch)
treea886a2b2502770feee97fa9cfc1e444ccfffcaa0 /Documentation/memory-barriers.txt
parente7720af5f9ac914577e2b810d5c004cdf395fd82 (diff)
downloadlinux-8d4840e84871847ee1bae56a776907d08a9265f7.tar.bz2
locking/Documentation: State purpose of memory-barriers.txt
There has been some confusion about the purpose of memory-barriers.txt, so this commit adds a statement of purpose. Signed-off-by: David Howells <dhowells@redhat.com> 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: linux-doc@vger.kernel.org Cc: will.deacon@arm.com Link: http://lkml.kernel.org/r/1461691328-5429-2-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'Documentation/memory-barriers.txt')
-rw-r--r--Documentation/memory-barriers.txt16
1 files changed, 16 insertions, 0 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index fb2dd35a823a..8b11e54238bf 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -19,6 +19,22 @@ 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.
+The purpose of this document is twofold:
+
+ (1) to specify the minimum functionality that one can rely on for any
+ particular barrier, and
+
+ (2) to provide a guide as to how to use the barriers that are available.
+
+Note that an architecture can provide more than the minimum requirement
+for any particular barrier, but if the architecure provides less than
+that, that architecture is incorrect.
+
+Note also that it is possible that a barrier may be a no-op for an
+architecture because the way that arch works renders an explicit barrier
+unnecessary in that case.
+
+
========
CONTENTS
========