Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422627AbaDQLxO (ORCPT ); Thu, 17 Apr 2014 07:53:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4912 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbaDQLxL (ORCPT ); Thu, 17 Apr 2014 07:53:11 -0400 Date: Thu, 17 Apr 2014 07:52:54 -0400 From: Jeff Layton To: "Stefan (metze) Metzmacher" Cc: mtk.manpages@gmail.com, libc-alpha , Michael Kerrisk-manpages , "Carlos O'Donell" , samba-technical@lists.samba.org, lkml , Jeremy Allison , "linux-fsdevel@vger.kernel.org" , Ganesha NFS List Subject: Re: should we change the name/macros of file-private locks? Message-ID: <20140417075254.28e470ed@tlielax.poochiereds.net> In-Reply-To: <534F0745.70705@samba.org> References: <20140416145746.66b7441c@tlielax.poochiereds.net> <534F0745.70705@samba.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Apr 2014 00:42:13 +0200 "Stefan (metze) Metzmacher" 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 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. > 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. Maybe we should just go with one of Michael's earlier suggestions -- "file-description locks" and change the macros to F_FD_*. 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? > > 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 -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/