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@xxxxxxxxxx> 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 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 >> this: >> >> F_FA_GETLK >> F_FA_SETLK >> F_FA_SETLKW With file-description-associated this could be F_FDA_* metze -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
