[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081008181223.6954c7b2.randy.dunlap@oracle.com>
Date: Wed, 8 Oct 2008 18:12:23 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Ben Hutchings <bhutchings@...arflare.com>
Cc: Mikulas Patocka <mpatocka@...hat.com>,
linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org
Subject: [PATCH] documentation: explain memory barriers
On Wed, 1 Oct 2008 22:54:04 -0700 Andrew Morton wrote:
> This sequence is repeated three or four times and should be pulled out
> into a well-commented function. That comment should explain the logic
> behind the use of these barriers, please.
and on 2008-OCT-08 Ben Hutchings wrote:
> All memory barriers need a comment to explain why and what they're doing.
Should this be added to CodingStyle or some other file?
From: Randy Dunlap <randy.dunlap@...cle.com>
We want all uses of memory barriers to be explained in the source
code.
Signed-off-by: Randy Dunlap <randy.dunlap@...cle.com>
---
Documentation/SubmitChecklist | 3 +++
1 file changed, 3 insertions(+)
--- lin2627-rc9-docs.orig/Documentation/SubmitChecklist
+++ lin2627-rc9-docs/Documentation/SubmitChecklist
@@ -85,3 +85,6 @@ kernel patches.
23: Tested after it has been merged into the -mm patchset to make sure
that it still works with all of the other queued patches and various
changes in the VM, VFS, and other subsystems.
+
+24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the
+ source code that explains the logic of what they are doing and why.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists