On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote:> On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index a61be39c7b51..433326ebdc26 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -1,3 +1,4 @@ > + > ===========================> LINUX KERNEL MEMORY BARRIERS > ===========================> @@ -5,6 +6,22 @@ > By: David Howells <dhowells at redhat.com> > Paul E. McKenney <paulmck at linux.vnet.ibm.com> > > +=========> +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.It might be worth adding you and me to the top of the file, to save Paul Cc'ing us on questions (get_maintainer.pl points at poor old Corbet for this file). But yes, it seems that something like this is required. Will
On Tue, Jan 26, 2016 at 11:09:27AM +0000, Will Deacon wrote:> On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > > specification (I seem to keep repeating this). > > > > Do we want this ?Seems likely to me. ;-)> > --- > > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > index a61be39c7b51..433326ebdc26 100644 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -1,3 +1,4 @@ > > + > > ===========================> > LINUX KERNEL MEMORY BARRIERS > > ===========================> > @@ -5,6 +6,22 @@ > > By: David Howells <dhowells at redhat.com> > > Paul E. McKenney <paulmck at linux.vnet.ibm.com> > > > > +=========> > +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. > > It might be worth adding you and me to the top of the file, to save Paul > Cc'ing us on questions (get_maintainer.pl points at poor old Corbet for > this file). > > But yes, it seems that something like this is required.So Peter, would you like to update your patch to include yourself and Will as authors? Thanx, Paul
On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote:> So Peter, would you like to update your patch to include yourself > and Will as authors?Sure, here goes. --- Subject: 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 at infradead.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 a61be39c7b51..98626125f484 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -4,8 +4,24 @@ By: David Howells <dhowells at redhat.com> Paul E. McKenney <paulmck at linux.vnet.ibm.com> + Will Deacon <will.deacon at arm.com> + Peter Zijlstra <peterz at 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. + +I repeat, this document is not a specification of what Linux expects from +hardware. + +=======+CONTENTS +======= (*) Abstract memory access model.
Peter Zijlstra <peterz at infradead.org> wrote:> +=========> +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. > + > +I 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 barrier provides less than that, it 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.> +Can you bung an extra blank line in here if you have to redo this at all?> +=======> +CONTENTS > +=======> > (*) Abstract memory access model. >David