This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] locks: rename file-private locks to file-description locks
- From: Rich Felker <dalias at libc dot org>
- To: Theodore Ts'o <tytso at mit dot edu>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Jeff Layton <jlayton at redhat dot com>, linux-fsdevel at vger dot kernel dot org, linux-kernel at vger dot kernel dot org, samba-technical at lists dot samba dot org, Ganesha NFS List <nfs-ganesha-devel at lists dot sourceforge dot net>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, "Stefan (metze) Metzmacher" <metze at samba dot org>, Christoph Hellwig <hch at infradead dot org>
- Date: Mon, 21 Apr 2014 16:20:59 -0400
- Subject: Re: [PATCH] locks: rename file-private locks to file-description locks
- Authentication-results: sourceware.org; auth=none
- References: <1398087935-14001-1-git-send-email-jlayton at redhat dot com> <20140421140246 dot GB26358 at brightrain dot aerifal dot cx> <535529FA dot 8070709 at gmail dot com> <20140421161004 dot GC26358 at brightrain dot aerifal dot cx> <5355644C dot 7000801 at gmail dot com> <20140421184841 dot GA5105 at thunk dot org> <20140421185144 dot GF26358 at brightrain dot aerifal dot cx> <20140421190410 dot GC5105 at thunk dot org>
On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 21, 2014 at 02:51:44PM -0400, Rich Felker wrote:
> > I don't think "struct file" has any meaning to any userspace
> > developers, and as such doesn't belong in documentation for userspace
> > programming. It's an implementation detail of the kernel that
> > userspace developers have no need to be aware of. There's already
> > enough leakage of broken kernel internals (e.g. tid vs pid vs tgid)
> > into userspace documentation that's immensely confusing for new
> > developers without adding more of it.
>
> Userspace programmers who are using dup(2) or dup(2) need to
> understand this "implementation detail". The fact that the file
No they don't. They need to understand the concept of an open file
description, not the kernel's "struct file" which is one (of many)
possible implementation of that. Irrelevant implementation details do
not belong in documentation.
Rich