On Wed, 2012-07-11 at 17:48 +0200, Kay Sievers wrote:
> On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
