[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1414626810.2542.5.camel@perches.com>
Date: Wed, 29 Oct 2014 16:53:30 -0700
From: Joe Perches <joe@...ches.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFA][PATCH 1/8] seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public
On Wed, 2014-10-29 at 19:42 -0400, Steven Rostedt wrote:
> On Wed, 29 Oct 2014 15:08:36 -0700 Joe Perches <joe@...ches.com> wrote:
> > On Wed, 2014-10-29 at 17:56 -0400, Steven Rostedt wrote:
> > > +A true return from seq_has_overflowed means that the seq_file buffer is full
> > > +and further output will be discarded.
> > Perhaps the description is a bit unclear here.
> > Doesn't a return of true to seq_has_overflowed mean that
> > more characters have already been written than the buffer
> > can accept?
> Actually, right now the comment is correct and the name is misleading.
> But I have a patch that will make the comment incorrect (and will be
> fixed) and the name correct.
>
> But since seq_has_overflowed() is to be used throughout the kernel, I
> didn't want to have to go do patches all over again for a temporary
> misnomer.
I think it'd be better if the first submission
of the function has the correct operation for
the name.
> In other words, I'm going to change the function to really return only
> if it did overflow and not just be full. But that's another patch set
> to come.
Why would it be a set and not a single patch?
--
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