linux-kernel - Re: should we change the name/macros of file-private locks?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140417075254.28e470ed@tlielax.poochiereds.net>
Date:	Thu, 17 Apr 2014 07:52:54 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	"Stefan (metze) Metzmacher" <metze@...ba.org>
Cc:	mtk.manpages@...il.com, libc-alpha <libc-alpha@...rceware.org>,
	Michael Kerrisk-manpages <mtk.manpages@...glemail.com>,
	"Carlos O'Donell" <carlos@...hat.com>,
	samba-technical@...ts.samba.org,
	lkml <linux-kernel@...r.kernel.org>,
	Jeremy Allison <jra@...gle.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Ganesha NFS List <nfs-ganesha-devel@...ts.sourceforge.net>
Subject: Re: should we change the name/macros of file-private locks?

On Thu, 17 Apr 2014 00:42:13 +0200
"Stefan (metze) Metzmacher" <metze@...ba.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@...hat.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
> >> 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 <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/