From: Matthew Wilcox <matthew@wil.cx>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@linux.intel.com>
Subject: Re: [PATCH 1/4] stringbuf: A string buffer implementation
Date: Tue, 23 Oct 2007 20:30:35 -0600 [thread overview]
Message-ID: <20071024023035.GV27248@parisc-linux.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0710231641480.30120@woody.linux-foundation.org>
On Tue, Oct 23, 2007 at 04:43:53PM -0700, Linus Torvalds wrote:
> On Tue, 23 Oct 2007, Matthew Wilcox wrote:
> > This is a generic string buffer which can also be used for non-printk
> > purposes. There is no sb_scanf implementation yet as I haven't identified
> > a user for it.
>
> Hmm. Have you looked at the git "strbuf" code?
I hadn't. It's quite spookily similar in some ways. There's a lot of
things you've added because you presumably have use for them in git that
could easily be added once we had users for them in the kernel. There's
a few things stringbufs do that strbufs don't need to because they're in
userspace.
I can easily change the API at this point, so if renaming things will
make you happier, just say so.
> And stuff like "sb_string()" are just evil. The string is there. Just call
> it something better than "s", and let people just use "sb->buf" or
> something. Why make the interface harder to use than necessary?
It's a matter of taste ... some people prefer to use accessors for
everything, other people prefer to expose the underlying structure
directly. I have to confess to being influenced by Java in 1998-99,
so possibly I tend to go for accessors too often. Or possibly it's
just my experience of restructuring things in Linux where diffs would
be smaller if we only had used accessors for something. In any case,
I don't care to fight about this; if you want it to be called buf,
then buf it shall be called, and I'll get rid of sb_string.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2007-10-24 2:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-23 21:12 [PATCH 1/4] stringbuf: A string buffer implementation Matthew Wilcox
2007-10-23 21:12 ` [PATCH 2/4] isdn: Use stringbuf Matthew Wilcox
2007-10-23 21:12 ` [PATCH 3/4] sound: " Matthew Wilcox
2007-10-23 21:12 ` [PATCH 4/4] partitions: Fix non-atomic printk Matthew Wilcox
2007-10-24 14:18 ` [PATCH 3/4] sound: Use stringbuf Takashi Iwai
2007-10-24 16:01 ` Matthew Wilcox
2007-10-24 14:50 ` Takashi Iwai
2007-10-23 22:11 ` [PATCH 1/4] stringbuf: A string buffer implementation Matt Mackall
2007-10-24 1:49 ` Matthew Wilcox
2007-10-24 15:20 ` Matt Mackall
2007-10-24 15:30 ` Matthew Wilcox
2007-10-23 23:43 ` Linus Torvalds
2007-10-24 2:30 ` Matthew Wilcox [this message]
2007-10-24 2:45 ` Andrew Morton
2007-10-24 2:19 ` Eric St-Laurent
2007-10-24 2:35 ` Matthew Wilcox
2007-10-24 2:48 ` Eric St-Laurent
2007-10-24 13:21 ` Florian Weimer
2007-10-24 14:02 ` Matthew Wilcox
2007-10-26 12:05 ` Pekka Enberg
2007-10-27 7:31 ` Pavel Machek
2007-10-30 15:26 ` Denys Vlasenko
-- strict thread matches above, loose matches on Subject: below --
2007-10-24 19:58 Stringbuf, v2 Matthew Wilcox
2007-10-24 19:59 ` [PATCH 1/4] stringbuf: A string buffer implementation Matthew Wilcox
2007-10-24 20:59 ` Kyle Moffett
2007-10-24 21:21 ` Matthew Wilcox
2007-10-25 0:07 ` Kyle Moffett
2007-10-25 3:23 ` Matthew Wilcox
2007-10-26 2:11 ` Rusty Russell
2007-10-26 3:41 ` Joe Perches
2007-10-26 5:05 ` Joe Perches
2007-10-26 11:57 ` Matthew Wilcox
2007-10-26 20:57 ` Matt Mackall
2007-10-27 10:09 ` Rusty Russell
2007-10-29 3:03 ` Matt Mackall
2007-10-29 5:38 ` Rusty Russell
2007-10-27 11:47 ` Pekka Enberg
2007-10-27 12:50 ` Rusty Russell
2007-10-27 16:34 ` Pekka Enberg
2007-10-27 16:48 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071024023035.GV27248@parisc-linux.org \
--to=matthew@wil.cx \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox