Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1376983 > unrolled thread

[PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire

Started by"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
First post2016-04-12 18:00 +0200
Last post2016-04-13 17:20 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-12 18:00 +0200
    [tip:locking/core] locking/Documentation: Fix missed s/lock/acquire  renames tip-bot for SeongJae Park <tipbot@zytor.com> - 2016-04-13 09:30 +0200
    Re: [PATCH memory-barriers.txt 2/7] documentation: Fix missed  renaming: s/lock/acquire Peter Zijlstra <peterz@infradead.org> - 2016-04-13 14:50 +0200
      Re: [PATCH memory-barriers.txt 2/7] documentation: Fix missed  renaming: s/lock/acquire "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-13 17:20 +0200

#1376983 — [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2016-04-12 18:00 +0200
Subject[PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire
Message-ID<rn8Tp-1ma-47@gated-at.bofh.it>
From: SeongJae Park <sj38.park@gmail.com>

Terms `lock` and `unlock` have changed to `acquire` / `release` by
commit 2e4f5382d12a441b5cccfdde00308df15c2ce300 ("locking/doc: Rename
LOCK/UNLOCK to ACQUIRE/RELEASE").  However, the commit missed to change
the table of content.  This commit changes the missed parts.
Also, section name `Acquiring functions` is not appropriate for the
section because the section is saying about lock in actual.  This commit
changes the name to more appropriate name, `Lock acquisition functions`.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Suggested-by: David Howells <dhowells@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 Documentation/memory-barriers.txt | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index ec1289042396..38b1ce161afb 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -31,15 +31,15 @@ Contents:
 
  (*) Implicit kernel memory barriers.
 
-     - Locking functions.
+     - Lock acquisition functions.
      - Interrupt disabling functions.
      - Sleep and wake-up functions.
      - Miscellaneous functions.
 
- (*) Inter-CPU locking barrier effects.
+ (*) Inter-CPU acquiring barrier effects.
 
-     - Locks vs memory accesses.
-     - Locks vs I/O accesses.
+     - Acquires vs memory accesses.
+     - Acquires vs I/O accesses.
 
  (*) Where are memory barriers needed?
 
@@ -1859,7 +1859,7 @@ This is a variation on the mandatory write barrier that causes writes to weakly
 ordered I/O regions to be partially ordered.  Its effects may go beyond the
 CPU->Hardware interface and actually affect the hardware at some level.
 
-See the subsection "Locks vs I/O accesses" for more information.
+See the subsection "Acquires vs I/O accesses" for more information.
 
 
 ===============================
@@ -1874,8 +1874,8 @@ provide more substantial guarantees, but these may not be relied upon outside
 of arch specific code.
 
 
-ACQUIRING FUNCTIONS
--------------------
+LOCK ACQUISITION FUNCTIONS
+--------------------------
 
 The Linux kernel has a number of locking constructs:
 
-- 
2.5.2

[toc] | [next] | [standalone]

#1377584 — [tip:locking/core] locking/Documentation: Fix missed s/lock/acquire renames

Fromtip-bot for SeongJae Park <tipbot@zytor.com>
Date2016-04-13 09:30 +0200
Subject[tip:locking/core] locking/Documentation: Fix missed s/lock/acquire renames
Message-ID<rnnpo-5TB-11@gated-at.bofh.it>
In reply to#1376983
Commit-ID:  166bda7122c8e817f039bf738cf05ab3b7278732
Gitweb:     http://git.kernel.org/tip/166bda7122c8e817f039bf738cf05ab3b7278732
Author:     SeongJae Park <sj38.park@gmail.com>
AuthorDate: Tue, 12 Apr 2016 08:52:50 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 13 Apr 2016 08:52:21 +0200

locking/Documentation: Fix missed s/lock/acquire renames

The terms 'lock'/'unlock' were changed to 'acquire'/'release' by the
following commit:

  2e4f5382d12a4 ("locking/doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE")

However, the commit missed to change the table of contents - fix that.

Also, the dumb rename changed the section name 'Locking functions' to an
actively misleading 'Acquiring functions' section name.

Rename it to 'Lock acquisition functions' instead.

Suggested-by: David Howells <dhowells@redhat.com>
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bobby.prani@gmail.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-2-git-send-email-paulmck@linux.vnet.ibm.com
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 Documentation/memory-barriers.txt | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index ec12890..38b1ce1 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -31,15 +31,15 @@ Contents:
 
  (*) Implicit kernel memory barriers.
 
-     - Locking functions.
+     - Lock acquisition functions.
      - Interrupt disabling functions.
      - Sleep and wake-up functions.
      - Miscellaneous functions.
 
- (*) Inter-CPU locking barrier effects.
+ (*) Inter-CPU acquiring barrier effects.
 
-     - Locks vs memory accesses.
-     - Locks vs I/O accesses.
+     - Acquires vs memory accesses.
+     - Acquires vs I/O accesses.
 
  (*) Where are memory barriers needed?
 
@@ -1859,7 +1859,7 @@ This is a variation on the mandatory write barrier that causes writes to weakly
 ordered I/O regions to be partially ordered.  Its effects may go beyond the
 CPU->Hardware interface and actually affect the hardware at some level.
 
-See the subsection "Locks vs I/O accesses" for more information.
+See the subsection "Acquires vs I/O accesses" for more information.
 
 
 ===============================
@@ -1874,8 +1874,8 @@ provide more substantial guarantees, but these may not be relied upon outside
 of arch specific code.
 
 
-ACQUIRING FUNCTIONS
--------------------
+LOCK ACQUISITION FUNCTIONS
+--------------------------
 
 The Linux kernel has a number of locking constructs:

[toc] | [prev] | [next] | [standalone]

#1377893 — Re: [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire

FromPeter Zijlstra <peterz@infradead.org>
Date2016-04-13 14:50 +0200
SubjectRe: [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire
Message-ID<rnsp3-1ia-3@gated-at.bofh.it>
In reply to#1376983
On Tue, Apr 12, 2016 at 08:52:50AM -0700, Paul E. McKenney wrote:
> From: SeongJae Park <sj38.park@gmail.com>
> 
> Terms `lock` and `unlock` have changed to `acquire` / `release` by
> commit 2e4f5382d12a441b5cccfdde00308df15c2ce300 ("locking/doc: Rename
> LOCK/UNLOCK to ACQUIRE/RELEASE").  However, the commit missed to change
> the table of content.  This commit changes the missed parts.
> Also, section name `Acquiring functions` is not appropriate for the
> section because the section is saying about lock in actual.  This commit
> changes the name to more appropriate name, `Lock acquisition functions`.
> 

True, because of this ppc thing :/

If we get PPC to switch to RCsc locks, there actually is a difference
again.

Given the current state I'm not sure how much we should care, but
there's a fundamental difference between things like load-acquire and
acquiring a lock, in that the lock-acquire must also very much imply a
store.

In any case, these are jet-lagged ramblings, feel free to ignore :-)

[toc] | [prev] | [next] | [standalone]

#1378041 — Re: [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2016-04-13 17:20 +0200
SubjectRe: [PATCH memory-barriers.txt 2/7] documentation: Fix missed renaming: s/lock/acquire
Message-ID<rnuKe-3cP-29@gated-at.bofh.it>
In reply to#1377893
On Wed, Apr 13, 2016 at 02:46:51PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 12, 2016 at 08:52:50AM -0700, Paul E. McKenney wrote:
> > From: SeongJae Park <sj38.park@gmail.com>
> > 
> > Terms `lock` and `unlock` have changed to `acquire` / `release` by
> > commit 2e4f5382d12a441b5cccfdde00308df15c2ce300 ("locking/doc: Rename
> > LOCK/UNLOCK to ACQUIRE/RELEASE").  However, the commit missed to change
> > the table of content.  This commit changes the missed parts.
> > Also, section name `Acquiring functions` is not appropriate for the
> > section because the section is saying about lock in actual.  This commit
> > changes the name to more appropriate name, `Lock acquisition functions`.
> 
> True, because of this ppc thing :/
> 
> If we get PPC to switch to RCsc locks, there actually is a difference
> again.

On that, I must defer to Michael Ellerman.

> Given the current state I'm not sure how much we should care, but
> there's a fundamental difference between things like load-acquire and
> acquiring a lock, in that the lock-acquire must also very much imply a
> store.

Agreed, even given PPC's current lock implementation, load-acquire
and lock-acquire are at best similar, not identical.  That said, one
strong similarity is the effect on ordering.

> In any case, these are jet-lagged ramblings, feel free to ignore :-)

I think we went in opposite directions.  I was in UK last week.  ;-)

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web