This is the mail archive of the
mailing list for the glibc project.
Re: should we change the name/macros of file-private locks?
- From: "Stefan (metze) Metzmacher" <metze at samba dot org>
- To: mtk dot manpages at gmail dot com, Jeff Layton <jlayton at redhat dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, Michael Kerrisk-manpages <mtk dot manpages at googlemail dot com>, Carlos O'Donell <carlos at redhat dot com>, samba-technical at lists dot samba dot org, lkml <linux-kernel at vger dot kernel dot org>, Jeremy Allison <jra at google dot com>, "linux-fsdevel at vger dot kernel dot org" <linux-fsdevel at vger dot kernel dot org>, Ganesha NFS List <nfs-ganesha-devel at lists dot sourceforge dot net>
- Date: Thu, 17 Apr 2014 00:42:13 +0200
- Subject: Re: should we change the name/macros of file-private locks?
- Authentication-results: sourceware.org; auth=none
- Openpgp: id=0E53083F
- References: <20140416145746 dot 66b7441c at tlielax dot poochiereds dot net> <CAKgNAkgqZDcT0jda8XS+4HrJzXjzwehqciHbkNuAVY3fNkH4zQ at mail dot gmail dot com>
Am 16.04.2014 22:00, schrieb Michael Kerrisk (man-pages):
> [CC += Jeremy Allison]
> On Wed, Apr 16, 2014 at 8:57 PM, Jeff Layton <email@example.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
> The names I have suggested are:
> file-associated locks
> file-handle locks
> or (using POSIX terminology)
> file-description locks
I'd use file-handle, file-description or at least something that's
not associated to the "file" itself.
file-handle-associated or file-description-associated would also work.
> but that last might be a bit confusing to people who are not
> standards-aware. (The POSIX standard defines the thing that a "file
> descriptor" refers to as a "file description"; other people often call
> that thing a "file handle" or an "open file table entry" or a "struct
> file". The POSIX term is precise and unambiguous, but, unfortunately,
> the term is not common outside the standard and is also easily
> mistaken for "file descriptor".)
>> At the same time, he suggested that we rename the command macros since
>> the 'P' suffix would no longer be relevant. He suggested something like
With file-description-associated this could be