From: Jim Lieb <jlieb@panasas.com>
To: <nfs-ganesha-devel@lists.sourceforge.net>,
Jeremy Allison <jra@samba.org>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
libc-alpha <libc-alpha@sourceware.org>,
Jeff Layton <jlayton@redhat.com>,
Michael Kerrisk-manpages <mtk.manpages@googlemail.com>,
"Carlos O'Donell" <carlos@redhat.com>,
<samba-technical@lists.samba.org>,
lkml <linux-kernel@vger.kernel.org>,
Jeremy Allison <jra@google.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Re: [Nfs-ganesha-devel] should we change the name/macros of file-private locks?
Date: Wed, 16 Apr 2014 17:31:11 -0700 [thread overview]
Message-ID: <2369283.4ufWfMqZox@jlieb-e6410> (raw)
In-Reply-To: <20140416201633.GQ22791@samba2>
On Wednesday, April 16, 2014 13:16:33 Jeremy Allison wrote:
> On Wed, Apr 16, 2014 at 10:00:46PM +0200, Michael Kerrisk (man-pages) wrote:
> > [CC += Jeremy Allison]
> >
> > On Wed, Apr 16, 2014 at 8:57 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > > Sorry to spam so many lists, but I think this needs widespread
> > > distribution and consensus.
> > >
> > > File-private locks have been merged into Linux for v3.15, and *now*
> > > people are commenting that the name and macro definitions for the new
> > > file-private locks suck.
> > >
> > > ...and I can't even disagree. They do suck.
> > >
> > > We're going to have to live with these for a long time, so it's
> > > important that we be happy with the names before we're stuck with them.
> >
> > So, to add my perspective: The existing byte-range locking system has
> > persisted (despite egregious faults) for well over two decades. One
> > supposes that Jeff's new improved version might be around
> > at least as long. With that in mind, and before setting in stone (and
> > pushing into POSIX) a model of thinking that thousands of programmers
> > will live with for a long time, it's worth thinking about names.
> >
> > > Michael Kerrisk suggested several names but I think the only one that
> > > doesn't have other issues is "file-associated locks", which can be
> > > distinguished against "process-associated" locks (aka classic POSIX
> > > locks).
> >
> > The names I have suggested are:
> > file-associated locks
> >
> > or
> >
> > file-handle locks
> >
> > or (using POSIX terminology)
> >
> > file-description locks
>
> Thanks for the CC: Michael, but to be honest
> I don't really care what the name is, I just
> want the functionality. I can change our build
> system to cope with detecting it under any name
> you guys choose :-).
>
> Cheers,
>
> Jeremy.
I and the rest of the nfs-ganesha community are with Jeremy and samba wrt
names. We just want locks that work, i.e. Useful Locks ;)
Jim
>
> ----------------------------------------------------------------------------
> -- Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013
next prev parent reply other threads:[~2014-04-17 0:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 18:57 should we change the name/macros of file-private locks? Jeff Layton
2014-04-16 20:00 ` Michael Kerrisk (man-pages)
2014-04-16 20:16 ` Jeremy Allison
2014-04-17 0:31 ` Jim Lieb [this message]
2014-04-17 5:43 ` [Nfs-ganesha-devel] " Michael Kerrisk (man-pages)
2014-04-16 22:42 ` Stefan (metze) Metzmacher
2014-04-17 11:52 ` Jeff Layton
2014-04-17 12:04 ` Michael Kerrisk (man-pages)
2014-04-17 20:08 ` Michael Kerrisk (man-pages)
2014-04-17 23:47 ` Jeff Layton
2014-04-17 15:17 ` Stefan (metze) Metzmacher
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=2369283.4ufWfMqZox@jlieb-e6410 \
--to=jlieb@panasas.com \
--cc=carlos@redhat.com \
--cc=jlayton@redhat.com \
--cc=jra@google.com \
--cc=jra@samba.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=mtk.manpages@googlemail.com \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
--cc=samba-technical@lists.samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).