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]
Date:	Mon, 21 Apr 2014 10:02:46 -0400
From:	Rich Felker <dalias@...c.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	samba-technical@...ts.samba.org,
	Ganesha NFS List <nfs-ganesha-devel@...ts.sourceforge.net>,
	Carlos O'Donell <carlos@...hat.com>,
	libc-alpha <libc-alpha@...rceware.org>,
	"Stefan (metze) Metzmacher" <metze@...ba.org>,
	Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH] locks: rename file-private locks to file-description
 locks

On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
> 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. The names and command macros 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.
> 
> The consensus on the lists so far is that they should be rechristened as
> "file-description locks".
> 
> This patch makes the following changes that I think are necessary before
> v3.15 ships:
> 
> 1) rename the command macros to their new names. These end up in the uapi
>    headers and so are part of the external-facing API. It turns out that
>    glibc doesn't actually use the fcntl.h uapi header, but it's hard to
>    be sure that something else won't. Changing it now is safest.
> 
> 2) make the the /proc/locks output display these as type "FDLOCK"
> 
> The rest of the renaming can wait until v3.16, since everything else
> isn't visible outside of the kernel.

I'm sorry I didn't chime in on this earlier, but I really prefer the
(somewhat bad) current naming ("private") to the
ridiculously-confusing use of "FD" to mean "file descriptION" when
everybody is used to it meaning "file descriptOR". The potential for
confusion that these are "file descriptOR locks" (they're not) is much
more of a problem, IMO, than the confusion about what "private" means
(since it doesn't have an established meaning in this context.

Thus my vote is for leaving things the way the kernel did it already.

Rich
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ