should we change the name/macros of file-private locks?
Michael Kerrisk (man-pages)
mtk.manpages at gmail.com
Thu Apr 17 06:04:47 MDT 2014
On 04/17/2014 01:52 PM, Jeff Layton wrote:
> On Thu, 17 Apr 2014 00:42:13 +0200
> "Stefan (metze) Metzmacher" <metze at samba.org> wrote:
>> 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 <jlayton at 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
>>> 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.
> Yeah, I understand your point.
> I'm not keen on using "file-handle" as file handles have a completely
> different meaning in the context of something like NFS.
> "file-description-associated" is rather a mouthful. You Germans might
> go for that sort of thing, but it feels awkward to us knuckle-draggers
> that primarily speak English.
Even as a knuckle-dragger in the German-speaking world it feels like
a mouthful ;-). But, I think Stefan's preference is anyway for the
shorter term(s), IIUC.
> Maybe we should just go with one of Michael's earlier suggestions --
> "file-description locks" and change the macros to F_FD_*.
>From my perspective, and the few comments so far, "file-handle lock"
or "file-description lock" seems the way to go. I imagine some will
not be so happy with the latter term (because unfamiliar and
too similar to "file descriptor), but the open(2) man page has for
quite a long time now (9+ years) has followed POSIX in using the term
"open file description".
> In the docs we could take pains to point out that these are
> file-_description_ locks and not file-_descriptor_ locks, and outline
> why that is so (which is something I'm trying to make crystal clear in
> the docs anyway).
> Does anyone object to that?
Well, I'd be silly to object, but maybe we should still allow a day
for further comment?
>>> 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
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
More information about the samba-technical