Re: pr_cat() + CATSTR(name, size)?

[Joe Perches]

On Wed, 2012-07-11 at 17:48 +0200, Kay Sievers wrote:
> On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
> > Well, I think the malloc costs are pretty low
> > and could devolve pretty easily when OOM.
> 
> We need to avoid allocating memory in situations where we want to
> printk(), it's just not possible.

"it's just not possible???"  Kay, them's fightin' words. :)

> That's why all the kmsg/printk can
> not really do any plain malloc. All printk memory needs to be static,
> on the stack or somehow pre-allocated.

Maybe, I was planning to play with it after
refactoring printk in the next couple releases.

> > Anyway, interesting idea, keep at it, see what
> > comes out of it.
> 
> Just depends on us, I guess. :)

Yup.

If your solution is just for the dev_<level> messages
(ie: with vprintk_emit descriptors), then it's not
too ugly.

Did you look at the remaining dev_<level> and printk
continuations grep pattern?  There really aren't too
many to fix up.

Maybe in 3.6.  None of them appear particularly urgent.

One trivial style note:

Maybe CATSTR could use a struct and a DECLARE_ macro?

struct printk_continuation_buffer {
	size_t length;
	size_t pos;
	char buf[];
}

It's a pity gcc doesn't allow non-static declarations like:

#define DECLARE_PRINTK_BUF(name, size)		\
struct printk_continuation_buffer name = {	\
	.length = size;				\
	.pos = 0;				\
	.buf[size] = {0};			\
}

So maybe a DECLARE/DESTROY thing could work
with the appropriate malloc/free.

cheers, Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/