On Tuesday 23 October 2007 22:12, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is no
On Monday 29 October 2007 14:03:52 Matt Mackall wrote:
> And on SLOB, which doesn't have those bloaty power-of-2 constraints?
> Looks like ~500 reallocs, including 25 bytes of memcpy. Ouch!
In other words, the system was compiled for size optimization and that's
what happened.
The question is
On Sat, Oct 27, 2007 at 08:09:30PM +1000, Rusty Russell wrote:
> On Saturday 27 October 2007 06:57:14 Matt Mackall wrote:
> > Well I expect once you start letting people easily build strings by
> > concatenation, you'll very shortly afterwards have people using them
> > in loops. And having hidden
On Tue 2007-10-23 17:12:43, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is no sb_sca
On Sat, Oct 27, 2007 at 07:34:47PM +0300, Pekka Enberg wrote:
> On 10/27/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> > > Why don't we just return -ENOMEM here just like all other APIs in the
> > > kernel?
> > I think Willy did it becau
Hi Rusty,
On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> > > + kfree(oldsb);
> > > + *sb = (struct stringbuf *)enomem_string;
> >
> > Why don't we just return -ENOMEM here just like all other APIs in the
> > kernel?
On 10/27/07, Rusty Russell <[EMAIL PROTEC
On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> Hi Rusty,
Hi Pekka,
> On 10/26/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > How about this? It's as simple as I could make it...
>
> FWIW I like this patch better.
Thanks.
> > + kfree(oldsb);
> > + *sb =
Hi Rusty,
On 10/26/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
>This just seems like more optimization and complexity that we need.
> Interfaces
> using vsnprintf don't seem like good candidates for optimization.
>
> How about this? It's as simple as I could make it...
FWIW I like thi
On Saturday 27 October 2007 06:57:14 Matt Mackall wrote:
> Well I expect once you start letting people easily build strings by
> concatenation, you'll very shortly afterwards have people using them
> in loops. And having hidden O(n^2) behavior in there is a little sad,
> even though n will tend t
On Fri, Oct 26, 2007 at 05:57:27AM -0600, Matthew Wilcox wrote:
> On Fri, Oct 26, 2007 at 12:11:01PM +1000, Rusty Russell wrote:
> > This just seems like more optimization and complexity that we need.
> > Interfaces
> > using vsnprintf don't seem like good candidates for optimization.
>
> Th
Hi,
On 10/24/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> +static void sb_vprintf(struct stringbuf *sb, const char *format, va_list
> args)
> +{
> + char *s;
> + int size;
> +
> + if (sb->alloc == -ENOMEM)
> + return;
> + if (sb->alloc == 0) {
> +
On Fri, Oct 26, 2007 at 12:11:01PM +1000, Rusty Russell wrote:
> This just seems like more optimization and complexity that we need.
> Interfaces
> using vsnprintf don't seem like good candidates for optimization.
That's a fair point, but I'm optimising for fewer trips into the
slab(/slub/
Perhaps have an sb_alloc function and a failure mode that
uses printk when sb_alloc fails or sb_append is passed null?
Perhaps something like:
stringbuf *sb_alloc(char* level, gfp_t priority)
{
stringbuf *sb = kmalloc(sizeof(*sb), priority);
if (sb)
sb>len = sprint
On Fri, 2007-10-26 at 12:11 +1000, Rusty Russell wrote:
> On Thursday 25 October 2007 05:59:49 Matthew Wilcox wrote:
> > Consecutive calls to printk are non-atomic, which leads to various
> > implementations for accumulating strings which can be printed in one call.
> > This is a generic string buf
On Thursday 25 October 2007 05:59:49 Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is
On Wed, Oct 24, 2007 at 08:07:23PM -0400, Kyle Moffett wrote:
> No, the problem is what happens when you don't have enough space
> allocated: you call "vsnprintf(s, len, format, args);" and then
> later call "vsprintf(s, format, args);" with the *SAME* "args".
> That's what's broken.
Ah, g
On Oct 24, 2007, at 17:21:10, Matthew Wilcox wrote:
On Wed, Oct 24, 2007 at 04:59:48PM -0400, Kyle Moffett wrote:
This seems unlikely to work reliably as the various "v*printf"
functions modify the va_list argument they are passed. It may
happen to work on your particular architecture depend
On Wed, Oct 24, 2007 at 04:59:48PM -0400, Kyle Moffett wrote:
> This seems unlikely to work reliably as the various "v*printf"
> functions modify the va_list argument they are passed. It may happen
> to work on your particular architecture depending on how that
> argument data is passed and
On Oct 24, 2007, at 15:59:49, Matthew Wilcox wrote:
+static void sb_vprintf(struct stringbuf *sb, gfp_t gfp, const char
*format, va_list args)
+{
[...]
+ s = sb->buf + sb->len;
+ size = vsnprintf(s, sb->alloc - sb->len, format, args);
[...]
+ /* Point to the end of the old st
Consecutive calls to printk are non-atomic, which leads to various
implementations for accumulating strings which can be printed in one call.
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 i
On Wed, Oct 24, 2007 at 10:20:36AM -0500, Matt Mackall wrote:
> On Tue, Oct 23, 2007 at 07:49:20PM -0600, Matthew Wilcox wrote:
> > I presume slob is different? Actually, slob doesn't seem to
> > provide krealloc, so I think stringbuf won't work on slob. Will you
> > have time to fix this?
>
> h
On Tue, Oct 23, 2007 at 07:49:20PM -0600, Matthew Wilcox wrote:
> On Tue, Oct 23, 2007 at 05:11:16PM -0500, Matt Mackall wrote:
> > You might want to consider growing the buffer by no less than a small
> > constant factor like 1.3x. This will keep things that do short concats
> > in a loop from deg
On Wed, Oct 24, 2007 at 03:21:06PM +0200, Florian Weimer wrote:
> > +struct stringbuf {
> > + char *s;
> > + int alloc;
> > + int len;
> > +};
>
> I think alloc and len should be unsigned (including some return values
> in the remaining patch).
I don't. Strings should never be as long as 2
* Matthew Wilcox:
> +struct stringbuf {
> + char *s;
> + int alloc;
> + int len;
> +};
I think alloc and len should be unsigned (including some return values
in the remaining patch).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, 2007-10-23 at 20:35 -0600, Matthew Wilcox wrote:
[...]
> > Multiple string objects can share the same data, by increasing the nrefs
> > count, a new data is allocated if the string is modified and nrefs > 1.
>
> If we were trying to get rid of char * throughout the kernel, that might
>
On Tue, 23 Oct 2007 20:30:35 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> It's a matter of taste ... some people prefer to use accessors for
> everything, other people prefer to expose the underlying structure
> directly.
Experience tells us that when you use accessors you end up thanking
yo
On Tue, Oct 23, 2007 at 10:19:06PM -0400, Eric St-Laurent wrote:
> I don't know if copy-on-write semantics are really useful for current
> in-kernel uses, but I've coded and used a C++ string class like this in
> the past:
CoW isn't in the slightest bit helpful. The point of these is to
provide a
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
On Tue, 2007-10-23 at 17:12 -0400, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is n
On Tue, Oct 23, 2007 at 05:11:16PM -0500, Matt Mackall wrote:
> You might want to consider growing the buffer by no less than a small
> constant factor like 1.3x. This will keep things that do short concats
> in a loop from degrading to O(n^2) performance due to realloc and
> memcpy.
I looked at s
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?
And stuff like "sb_string()" are jus
On Tue, Oct 23, 2007 at 05:12:43PM -0400, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. Ther
Consecutive calls to printk are non-atomic, which leads to various
implementations for accumulating strings which can be printed in one call.
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 i
33 matches
Mail list logo
