On Wed, 5 Nov 2014 16:57:11 +0100 Petr Mladek <pmla...@suse.cz> wrote:
> On Tue 2014-11-04 10:52:42, Steven Rostedt wrote: > > From: "Steven Rostedt (Red Hat)" <rost...@goodmis.org> > > > > In facilitating the conversion of seq_file to use seq_buf, > > have the seq_buf fields match the types used by seq_file. > > > > Signed-off-by: Steven Rostedt <rost...@goodmis.org> > > --- > > include/linux/seq_buf.h | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/seq_buf.h b/include/linux/seq_buf.h > > index 6d1c57d6073f..a4d114e6f740 100644 > > --- a/include/linux/seq_buf.h > > +++ b/include/linux/seq_buf.h > > @@ -19,10 +19,10 @@ > > * @overflow: Set if more bytes should have been written to buffer > > */ > > struct seq_buf { > > - unsigned char *buffer; > > - unsigned int size; > > - unsigned int len; > > - unsigned int readpos; > > + char *buffer; > > It would make sense to use "char" from the beginning. In fact, it is > already used on many locations in seq_buf.c. Or we might want to get > rid of "unsigned char" in seq_buf.c here as well. I could, but I'm being lazy ;-) No reason to change the patch series for something as small as this. It doesn't break bisect. > > > + size_t size; > > + size_t len; > > + loff_t readpos; > > I have just noticed that the variable is called "read_pos" in > seq_file. Are you going to sync the name later? Yeah, I purposely kept them different to find the two when needed. > > Also I am a bit curious that "readpos" use another type than "len" > and "size". Well, this is not in the scope of this patchset. I am fine > with keeping "loff_t" at this point. Again, seq_file has been around for a long time with these types. But as you said, it's out of scope for this patch series. I'm just trying to keep with what's been the norm here. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/