Re: [PATCH v2 2/2] manual/llio.texi: update manual to document file-private locks

[Michael Kerrisk <mtk dot manpages at gmail dot com>]

Jeff, (and Carlos)

> On Sat, 12 Apr 2014 12:52:33 -0400
> "Carlos O'Donell" <carlos@redhat.com> wrote:

[...]


>> OT: Why is it F_*LKP? What does the "P" part of "LKP" mean?

That does not strike me as OT at all. 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.

> Sorry, forgot to answer this:
>
> "P" is for "Private". What can I say...I suck at naming things, and no
> one else proposed anything better. It's not too late to change that if
> you can come up with a better moniker, but we'd need to move fast
> before v3.15 ships.

I agree on the "suck" bit ;-). Carlos nailed it when he referred to
traditional byte-range locks as being "process-associated". That is
the distinction between these two two locking APIs: one associates
locks with the process, the other associates them with a file handle.
The terminology should reflect that difference.

>From that perspective, the word "private" here makes no sense at all.
What does "private" mean in this context? (By their very definition,
file locks are not private--they're something that is visible between
processes.) Some thought should be given to fixing that name, now, so
that we have better terminology for the coming decades ;-).

I would at the least suggest renaming these locks to something like:

    file-associated locks

or

   file-handle locks

or (using POSIX terminology)

    file-description locks

but that last might be a bit confusing.

With some thought, you might also come up with an even better name.
But, I think *all* of the above alternatives are better than
"file-private locks".

Please consider moving to one of those pieces of terminology, or a
better one of your own creation. Note that also implies that the names
of the constants should probably change. (Already, I found the
spelling of F_SETLKPW a little strange, since I expected F_SETLKWP.)
For example, if you went with the "file handle" terminology, then
something like:

F_FH_SETLK
F_FH_SETLKW
F_FH_GETLK

That also has the advantage of making the new constants more visually
distinctive in code. (I could easily see someone accidentally omitting
the "P" in F_SETLKP, and it would not be immediately obvious at a
casual scan.)

Cheers,

Michael