[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140421202059.GG26358@brightrain.aerifal.cx>
Date: Mon, 21 Apr 2014 16:20:59 -0400
From: Rich Felker <dalias@...c.org>
To: Theodore Ts'o <tytso@....edu>,
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
Jeff Layton <jlayton@...hat.com>,
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>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] locks: rename file-private locks to file-description
locks
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
--
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