On 04/29/2014 01:34 PM, Jeff Layton wrote:
> On Tue, 29 Apr 2014 11:53:40 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> On 04/29/2014 11:24 AM, NeilBrown wrote:
>>> On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
>>> wrote:
>>>
On 04/27/2014 11:28 PM, NeilBrown wrote:
On Tue, 29 Apr 2014 11:53:40 +0200
"Michael Kerrisk (man-pages)" wrote:
> On 04/29/2014 11:24 AM, NeilBrown wrote:
> > On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
> > wrote:
> >
> >> On 04/27/2014 11:28 PM, NeilBrown wrote:
> >>> On Sun, 27 Apr 2014 13:11:33 +0200 "Michael
On 04/29/2014 11:24 AM, NeilBrown wrote:
> On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
> wrote:
>
>> On 04/27/2014 11:28 PM, NeilBrown wrote:
>>> On Sun, 27 Apr 2014 13:11:33 +0200 "Michael Kerrisk (man-pages)"
>>> wrote:
>>>
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown
On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
wrote:
> On 04/27/2014 11:28 PM, NeilBrown wrote:
> > On Sun, 27 Apr 2014 13:11:33 +0200 "Michael Kerrisk (man-pages)"
> > wrote:
> >
> >> On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown wrote:
> >>> On Sun, 27 Apr 2014 11:16:02
On 04/27/2014 11:28 PM, NeilBrown wrote:
> On Sun, 27 Apr 2014 13:11:33 +0200 "Michael Kerrisk (man-pages)"
> wrote:
>
>> On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown wrote:
>>> On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
>>> wrote:
>>>
[Trimming some folk from CC, and
On 04/27/2014 11:28 PM, NeilBrown wrote:
On Sun, 27 Apr 2014 13:11:33 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown ne...@suse.de wrote:
On Sun, 27 Apr 2014 11:16:02 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Tue, 29 Apr 2014 11:07:16 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/27/2014 11:28 PM, NeilBrown wrote:
On Sun, 27 Apr 2014 13:11:33 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown ne...@suse.de
On 04/29/2014 11:24 AM, NeilBrown wrote:
On Tue, 29 Apr 2014 11:07:16 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/27/2014 11:28 PM, NeilBrown wrote:
On Sun, 27 Apr 2014 13:11:33 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Sun, Apr 27, 2014
On Tue, 29 Apr 2014 11:53:40 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/29/2014 11:24 AM, NeilBrown wrote:
On Tue, 29 Apr 2014 11:07:16 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/27/2014 11:28 PM, NeilBrown wrote:
On Sun, 27 Apr
On 04/29/2014 01:34 PM, Jeff Layton wrote:
On Tue, 29 Apr 2014 11:53:40 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/29/2014 11:24 AM, NeilBrown wrote:
On Tue, 29 Apr 2014 11:07:16 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/27/2014 11:28
On Mon, 28 Apr 2014 06:23:21 -0400 Jeff Layton wrote:
> I sent a pull request to Linus last week and he merged the patches over
> the weekend. So yes, this ship has sailed unless someone feels strongly
> enough about it to roll up the patches to change it.
>
> I think we'll probably come to
On Sun, 27 Apr 2014 14:51:25 +1000
NeilBrown wrote:
> On Tue, 22 Apr 2014 06:54:36 +0200 "Michael Kerrisk (man-pages)"
> wrote:
>
> > On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
> > > Am 21.04.2014 21:55, schrieb Jeff Layton:
> > >> On Mon, 21 Apr 2014 21:39:12 +0200
> > >>
On Sun, 27 Apr 2014 14:51:25 +1000
NeilBrown ne...@suse.de wrote:
On Tue, 22 Apr 2014 06:54:36 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014
On Mon, 28 Apr 2014 06:23:21 -0400 Jeff Layton jlay...@redhat.com wrote:
I sent a pull request to Linus last week and he merged the patches over
the weekend. So yes, this ship has sailed unless someone feels strongly
enough about it to roll up the patches to change it.
I think we'll
On Sun, 27 Apr 2014 13:11:33 +0200 "Michael Kerrisk (man-pages)"
wrote:
> On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown wrote:
> > On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
> > wrote:
> >
> >> [Trimming some folk from CC, and adding various NFS people]
> >>
> >> On
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown wrote:
> On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
> wrote:
>
>> [Trimming some folk from CC, and adding various NFS people]
>>
>> On 04/27/2014 06:51 AM, NeilBrown wrote:
>>
>> [...]
>>
>> > Note to Michael: The text
>> >
On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
wrote:
> [Trimming some folk from CC, and adding various NFS people]
>
> On 04/27/2014 06:51 AM, NeilBrown wrote:
>
> [...]
>
> > Note to Michael: The text
> >flock() does not lock files over NFS.
> > in flock(2) is no
On 04/27/2014 06:51 AM, NeilBrown wrote:
> On Tue, 22 Apr 2014 06:54:36 +0200 "Michael Kerrisk (man-pages)"
> wrote:
>
>> On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
>>> Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014 21:39:12 +0200
"Michael Kerrisk
[Trimming some folk from CC, and adding various NFS people]
On 04/27/2014 06:51 AM, NeilBrown wrote:
[...]
> Note to Michael: The text
>flock() does not lock files over NFS.
> in flock(2) is no longer accurate. The reality is ... complex.
> See nfs(5), and search for "local_lock".
Ahhh --
On Sun, 27 Apr 2014 13:11:33 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown ne...@suse.de wrote:
On Sun, 27 Apr 2014 11:16:02 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
[Trimming some folk from CC, and
On 04/27/2014 06:51 AM, NeilBrown wrote:
On Tue, 22 Apr 2014 06:54:36 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014 21:39:12 +0200
Michael Kerrisk
[Trimming some folk from CC, and adding various NFS people]
On 04/27/2014 06:51 AM, NeilBrown wrote:
[...]
Note to Michael: The text
flock() does not lock files over NFS.
in flock(2) is no longer accurate. The reality is ... complex.
See nfs(5), and search for local_lock.
Ahhh -- I
On Sun, 27 Apr 2014 11:16:02 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
[Trimming some folk from CC, and adding various NFS people]
On 04/27/2014 06:51 AM, NeilBrown wrote:
[...]
Note to Michael: The text
flock() does not lock files over NFS.
in flock(2) is
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown ne...@suse.de wrote:
On Sun, 27 Apr 2014 11:16:02 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
[Trimming some folk from CC, and adding various NFS people]
On 04/27/2014 06:51 AM, NeilBrown wrote:
[...]
Note to Michael: The
On Tue, 22 Apr 2014 06:54:36 +0200 "Michael Kerrisk (man-pages)"
wrote:
> On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
> > Am 21.04.2014 21:55, schrieb Jeff Layton:
> >> On Mon, 21 Apr 2014 21:39:12 +0200
> >> "Michael Kerrisk (man-pages)" wrote:
> >>
> >>> On 04/21/2014 08:46 PM,
On Tue, 22 Apr 2014 06:54:36 +0200 Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014 21:39:12 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
> Am 21.04.2014 21:55, schrieb Jeff Layton:
>> On Mon, 21 Apr 2014 21:39:12 +0200
>> "Michael Kerrisk (man-pages)" wrote:
>>
>>> On 04/21/2014 08:46 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk
Am 21.04.2014 21:55, schrieb Jeff Layton:
> On Mon, 21 Apr 2014 21:39:12 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> On 04/21/2014 08:46 PM, Rich Felker wrote:
>>> On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
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
On Mon, Apr 21, 2014 at 03:16:29PM -0400, Jeff Layton wrote:
> On Mon, 21 Apr 2014 14:48:29 -0400
> Rich Felker wrote:
>
> > On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
> > > > > Fair enough. Assuming we kept "file-description locks" as a name, what
> > > > > would you propose
On 04/21/2014 09:06 PM, Christoph Hellwig wrote:
> On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
>> I think what you mean is that there is no need that we expose the name
>> "struct file". My point is that "struct file" is actually a much
>> _better_ name than "file description".
On Mon, 21 Apr 2014 21:39:12 +0200
"Michael Kerrisk (man-pages)" wrote:
> On 04/21/2014 08:46 PM, Rich Felker wrote:
> > On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
> >> On 04/21/2014 06:10 PM, Rich Felker wrote:
> >>> I'm well aware of that. The problem is that
On 04/21/2014 08:46 PM, Rich Felker wrote:
> On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
>> On 04/21/2014 06:10 PM, Rich Felker wrote:
>>> I'm well aware of that. The problem is that the proposed API is using
>>> the two-letter abbreviation FD, which ALWAYS means
On Mon, 21 Apr 2014 14:48:29 -0400
Rich Felker wrote:
> On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
> > > > Fair enough. Assuming we kept "file-description locks" as a name, what
> > > > would you propose as new macro names?
> > >
> > > I assume you meant, "assume we kept the
On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
> I think what you mean is that there is no need that we expose the name
> "struct file". My point is that "struct file" is actually a much
> _better_ name than "file description". Heck, "open file object" would
> be better name than
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
On Mon, Apr 21, 2014 at 02:48:41PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
> > So, can you *please* answer this question: what do you call (i.e.,
> > what everyday technical language term do use for) the thing
> > that sits
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
> So, can you *please* answer this question: what do you call (i.e.,
> what everyday technical language term do use for) the thing
> that sits between a file descriptor and an i-node?
>
> (Please don't say 'struct
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
> > > Fair enough. Assuming we kept "file-description locks" as a name, what
> > > would you propose as new macro names?
> >
> > I assume you meant, "assume we kept the term 'file-private locks'..."
> > In that case, at least make the
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
> On 04/21/2014 06:10 PM, Rich Felker wrote:
> > I'm well aware of that. The problem is that the proposed API is using
> > the two-letter abbreviation FD, which ALWAYS means file descriptor and
> > NEVER means file
On 04/21/2014 08:01 PM, Andy Lutomirski wrote:
> On 04/21/2014 09:45 AM, Jeff Layton wrote:
>> On Mon, 21 Apr 2014 12:10:04 -0400
>> Rich Felker wrote:
>>> I'm well aware of that. The problem is that the proposed API is using
>>> the two-letter abbreviation FD, which ALWAYS means file descriptor
On 04/21/2014 08:34 PM, Christoph Hellwig wrote:
> On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
>> So, can you *please* answer this question: what do you call (i.e.,
>> what everyday technical language term do use for) the thing
>> that sits between a file
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
> So, can you *please* answer this question: what do you call (i.e.,
> what everyday technical language term do use for) the thing
> that sits between a file descriptor and an i-node?
An open file.
--
To unsubscribe
On Mon, 21 Apr 2014 20:18:50 +0200
"Michael Kerrisk (man-pages)" wrote:
> Jeff,
> On 04/21/2014 06:45 PM, Jeff Layton wrote:
> > On Mon, 21 Apr 2014 12:10:04 -0400
> > Rich Felker wrote:
> >
> >> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages)
> >> wrote:
> >>> On
On 04/21/2014 06:10 PM, Rich Felker wrote:
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
>> On 04/21/2014 04:02 PM, Rich Felker wrote:
>>> On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
File-private locks have been merged into Linux for v3.15,
Christoph,
On 04/21/2014 06:09 PM, Christoph Hellwig wrote:
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
>>
>> There's at least two problems to solve here:
>>
>> 1) "File private locks" is _meaningless_ as a term. Elsewhere
>>
>>
Jeff,
On 04/21/2014 06:45 PM, Jeff Layton wrote:
> On Mon, 21 Apr 2014 12:10:04 -0400
> Rich Felker wrote:
>
>> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
>>> On 04/21/2014 04:02 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton
On 04/21/2014 09:45 AM, Jeff Layton wrote:
> On Mon, 21 Apr 2014 12:10:04 -0400
> Rich Felker wrote:
>> I'm well aware of that. The problem is that the proposed API is using
>> the two-letter abbreviation FD, which ALWAYS means file descriptor and
>> NEVER means file description (in existing
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages)
> wrote:
> >
> > There's at least two problems to solve here:
> >
> > 1) "File private locks" is _meaningless_ as a term. Elsewhere
> >
> >
> (http://thread.gmane.org/gmane.network.samba.internals/76414/focus=16
> 8
> > 5376),
On Mon, 21 Apr 2014 09:09:27 -0700
Christoph Hellwig wrote:
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
> >
> > There's at least two problems to solve here:
> >
> > 1) "File private locks" is _meaningless_ as a term. Elsewhere
> >
> >
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker wrote:
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
> > On 04/21/2014 04:02 PM, Rich Felker wrote:
> > > On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
> > >> File-private locks have been merged into
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
> On 04/21/2014 04:02 PM, Rich Felker wrote:
> > 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
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
>
> There's at least two problems to solve here:
>
> 1) "File private locks" is _meaningless_ as a term. Elsewhere
>
> (http://thread.gmane.org/gmane.network.samba.internals/76414/focus=1685376),
It's indeed not a
Am 21.04.2014 15:45, schrieb Jeff Layton:
> 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
On 04/21/2014 03:45 PM, Jeff Layton wrote:
[...]
> - * These cmd values will set locks that conflict with normal POSIX locks, but
> - * are "owned" by the opened file, not the process. This means that they are
> - * inherited across fork() like BSD (flock) locks, and they are only released
> - *
On 04/21/2014 04:02 PM, Rich Felker wrote:
> 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
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
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
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
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.
On 04/21/2014 04:02 PM, Rich Felker wrote:
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
On 04/21/2014 03:45 PM, Jeff Layton wrote:
[...]
- * These cmd values will set locks that conflict with normal POSIX locks, but
- * are owned by the opened file, not the process. This means that they are
- * inherited across fork() like BSD (flock) locks, and they are only released
- *
Am 21.04.2014 15:45, schrieb Jeff Layton:
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
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
There's at least two problems to solve here:
1) File private locks is _meaningless_ as a term. Elsewhere
(http://thread.gmane.org/gmane.network.samba.internals/76414/focus=1685376),
It's indeed not a very
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 04:02 PM, Rich Felker wrote:
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
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 04:02 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
File-private locks have been merged
On Mon, 21 Apr 2014 09:09:27 -0700
Christoph Hellwig h...@infradead.org wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
There's at least two problems to solve here:
1) File private locks is _meaningless_ as a term. Elsewhere
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages)
wrote:
There's at least two problems to solve here:
1) File private locks is _meaningless_ as a term. Elsewhere
(http://thread.gmane.org/gmane.network.samba.internals/76414/focus=16
8
5376),
It's indeed not
On 04/21/2014 09:45 AM, Jeff Layton wrote:
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file descriptor and
NEVER means file description (in
Jeff,
On 04/21/2014 06:45 PM, Jeff Layton wrote:
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 04:02 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff
Christoph,
On 04/21/2014 06:09 PM, Christoph Hellwig wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
There's at least two problems to solve here:
1) File private locks is _meaningless_ as a term. Elsewhere
On 04/21/2014 06:10 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 04:02 PM, Rich Felker wrote:
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*
On Mon, 21 Apr 2014 20:18:50 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
Jeff,
On 04/21/2014 06:45 PM, Jeff Layton wrote:
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages)
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
So, can you *please* answer this question: what do you call (i.e.,
what everyday technical language term do use for) the thing
that sits between a file descriptor and an i-node?
An open file.
--
To unsubscribe
On 04/21/2014 08:34 PM, Christoph Hellwig wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
So, can you *please* answer this question: what do you call (i.e.,
what everyday technical language term do use for) the thing
that sits between a file descriptor and
On 04/21/2014 08:01 PM, Andy Lutomirski wrote:
On 04/21/2014 09:45 AM, Jeff Layton wrote:
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file descriptor and
NEVER means file description
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
Fair enough. Assuming we kept file-description locks as a name, what
would you propose as new macro names?
I assume you meant, assume we kept the term 'file-private locks'...
In that case, at least make the constants
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
So, can you *please* answer this question: what do you call (i.e.,
what everyday technical language term do use for) the thing
that sits between a file descriptor and an i-node?
(Please don't say 'struct file' --
On Mon, Apr 21, 2014 at 02:48:41PM -0400, Theodore Ts'o wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
So, can you *please* answer this question: what do you call (i.e.,
what everyday technical language term do use for) the thing
that sits between a
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
On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
I think what you mean is that there is no need that we expose the name
struct file. My point is that struct file is actually a much
_better_ name than file description. Heck, open file object would
be better name than file
On Mon, 21 Apr 2014 14:48:29 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
Fair enough. Assuming we kept file-description locks as a name, what
would you propose as new macro names?
I assume you meant, assume we kept the term
On 04/21/2014 08:46 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file
On Mon, 21 Apr 2014 21:39:12 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/21/2014 08:46 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
I'm well aware of that. The
On 04/21/2014 09:06 PM, Christoph Hellwig wrote:
On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
I think what you mean is that there is no need that we expose the name
struct file. My point is that struct file is actually a much
_better_ name than file description. Heck, open
On Mon, Apr 21, 2014 at 03:16:29PM -0400, Jeff Layton wrote:
On Mon, 21 Apr 2014 14:48:29 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
Fair enough. Assuming we kept file-description locks as a name, what
would you propose as
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
Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014 21:39:12 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/21/2014 08:46 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote:
Am 21.04.2014 21:55, schrieb Jeff Layton:
On Mon, 21 Apr 2014 21:39:12 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On 04/21/2014 08:46 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk
90 matches
Mail list logo
