From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752766AbcDZRVk (ORCPT ); Tue, 26 Apr 2016 13:21:40 -0400 Received: from e17.ny.us.ibm.com ([129.33.205.207]:35606 "EHLO e17.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751974AbcDZRVi (ORCPT ); Tue, 26 Apr 2016 13:21:38 -0400 X-IBM-Helo: d01dlp03.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-doc@vger.kernel.org;linux-kernel@vger.kernel.org From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org Cc: mingo@kernel.org, corbet@lwn.net, peterz@infradead.org, linux-doc@vger.kernel.org, dhowells@redhat.com, will.deacon@arm.com, dave@stgolabs.net, "Paul E. McKenney" Subject: [PATCH locking 2/4] documentation: State purpose of memory-barriers.txt Date: Tue, 26 Apr 2016 10:22:06 -0700 Message-Id: <1461691328-5429-2-git-send-email-paulmck@linux.vnet.ibm.com> X-Mailer: git-send-email 2.5.2 In-Reply-To: <20160426172041.GA4539@linux.vnet.ibm.com> References: <20160426172041.GA4539@linux.vnet.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042617-0041-0000-0000-000003F9BFBF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Howells 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 Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) 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 ======== -- 2.5.2