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 this patch better.
On 10/26/07, Rusty Russell <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
