All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <waiman.long@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Chandramouleeswaran, Aswin" <aswin@hp.com>,
	"Norton, Scott J" <scott.norton@hp.com>
Subject: Re: [PATCH 0/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() & friend
Date: Thu, 12 Sep 2013 13:36:05 -0400	[thread overview]
Message-ID: <5231FB85.7070206@hp.com> (raw)
In-Reply-To: <CA+55aFwsqHJE1D-z8_kU+1VEpUTB=EU57kqmKao580gYZVOjrw@mail.gmail.com>

On 09/12/2013 12:38 PM, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 7:55 AM, Waiman Long<Waiman.Long@hp.com>  wrote:
>> Change log
>> ----------
>> v1->v2:
>>    - Rename the new seqlock primitives to read_seqexcl_lock* and
>>      read_seqexcl_unlock*.
> Applied. Except I peed in the snow and renamed the functions
> again.That whole "seqexcl" looked too odd to me. It not only looks a
> bit too much like random noise, but it makes it seem a whole different
> lock from the "seqlock" thing.
>
> I wanted to pattern the name after "write_seq[un]lock()", since it
> most resembles that (not just in implementation, but in usage: the
> traditional read-sequence isn't a lock, it's a begin/retry sequence,
> so the usage pattern is totally different too, and the naming is
> different).
>
> I ended up picking "read_seq[un]lock_excl()". I could have gone with
> "excl_" as a prefix too, I guess. Whatever. Now the "_excl" thing
> looks a bit like the "_bh"/"_irqX" context modifier, and I think it
> matches our normal lock naming pattern better.
>
>              Linus

I think your new names are better than mine. I am not good at naming 
stuff. Thank for the merge and the rename.

-Longman

      parent reply	other threads:[~2013-09-12 17:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-12 14:55 [PATCH 0/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() & friend Waiman Long
2013-09-12 14:55 ` [PATCH 1/2 v2] seqlock: Add a new locking reader type Waiman Long
2013-09-12 14:55 ` [PATCH 2/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() & friend Waiman Long
2013-09-12 16:38 ` [PATCH 0/2 " Linus Torvalds
2013-09-12 17:30   ` Linus Torvalds
2013-09-12 19:01     ` Waiman Long
2013-09-12 19:04       ` Linus Torvalds
2013-09-12 21:56         ` Al Viro
2013-09-12 22:00           ` Linus Torvalds
2013-09-12 22:01             ` Linus Torvalds
2013-09-12 17:36   ` Waiman Long [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5231FB85.7070206@hp.com \
    --to=waiman.long@hp.com \
    --cc=aswin@hp.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott.norton@hp.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.