redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

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>
steinar/wifi_calib_4_9_kernel
David Howells 2016-04-26 10:22:06 -07:00 committed by Ingo Molnar
parent e7720af5f9
commit 8d4840e848
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Documentation/memory-barriers.txt
View File

@ -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
========