This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: should we change the name/macros of file-private locks?
- From: Jeremy Allison <jra at samba dot org>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Cc: Jeff Layton <jlayton at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, "linux-fsdevel at vger dot kernel dot org" <linux-fsdevel at vger dot kernel dot org>, lkml <linux-kernel at vger dot kernel dot org>, Carlos O'Donell <carlos at redhat dot com>, Michael Kerrisk-manpages <mtk dot manpages at googlemail dot com>, samba-technical at lists dot samba dot org, Ganesha NFS List <nfs-ganesha-devel at lists dot sourceforge dot net>, Jeremy Allison <jra at google dot com>
- Date: Wed, 16 Apr 2014 13:16:33 -0700
- Subject: Re: should we change the name/macros of file-private locks?
- Authentication-results: sourceware.org; auth=none
- References: <20140416145746 dot 66b7441c at tlielax dot poochiereds dot net> <CAKgNAkgqZDcT0jda8XS+4HrJzXjzwehqciHbkNuAVY3fNkH4zQ at mail dot gmail dot com>
- Reply-to: Jeremy Allison <jra at samba dot org>
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.