Re: [PATCH 1/4] stringbuf: A string buffer implementation

Pekka Enberg
2007-10-27T11:47:19Z

Hi Rusty,

On 10/26/07, Rusty Russell <rusty@rustcorp.com.au> 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 this patch better.

On 10/26/07, Rusty Russell <rusty@rustcorp.com.au> wrote:
> +void sb_printf_append(struct stringbuf **sb, gfp_t gfp, const char *fmt, ...)
> +{
> + unsigned int fmtlen, len;
> + va_list args;
> + struct stringbuf *oldsb = *sb;
> +
> + if (oldsb->buf == enomem_string)
> + return;
> +
> + va_start(args, fmt);
> + fmtlen = vsnprintf(NULL, 0, fmt, args);
> + va_end(args);
> +
> + len = oldsb ? strlen(oldsb->buf) : 0;
> + *sb = krealloc(oldsb, len + fmtlen + 1, gfp);
> + if (!*sb) {
> + kfree(oldsb);
> + *sb = (struct stringbuf *)enomem_string;

Why don't we just return -ENOMEM here just like all other APIs in the
kernel? And I wonder if it makes more sense to store gfp_flags in
struct stringbuf and always use that? I mean, why would you want to
sometimes do GFP_ATOMIC and GFP_KERNEL allocations for the same
buffer?

Pekka