[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160414214054.GB31866@linux.vnet.ibm.com>
Date: Thu, 14 Apr 2016 14:40:54 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will.deacon@....com>,
Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
linux-arch@...r.kernel.org,
Andrew Cooper <andrew.cooper3@...rix.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
virtualization@...ts.linux-foundation.org,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Joe Perches <joe@...ches.com>,
David Miller <davem@...emloft.net>, linux-ia64@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
sparclinux@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
x86@...nel.org, user-mode-linux-devel@...ts.sourceforge.net,
adi-buildroot-devel@...ts.sourceforge.net,
linux-sh@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
xen-devel@...ts.xenproject.org, Ralf Baechle <ralf@...ux-mips.org>,
Ingo Molnar <mingo@...nel.org>, ddaney.cavm@...il.com,
james.hogan@...tec.com, Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH] documentation: Add disclaimer
On Wed, Jan 27, 2016 at 02:57:07PM +0000, David Howells wrote:
> Peter Zijlstra <peterz@...radead.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?
Done as part of your patch. Again, apologies for the delay.
Thanx, Paul
> > +========
> > +CONTENTS
> > +========
> >
> > (*) Abstract memory access model.
> >
>
> David
>
Powered by blists - more mailing lists