> I think we're talking about slightly different things. I'd agree that
> one call to printk is atomic, and won't get interspersed with other
> things, but if we output a line via multiple calls to printk, then I
> think we have a problem. Say CPU 0 executes this bit of code:
>
> for (i=0; i<10; i++) { printk ("%d ", i); } printk("\n");
>
> and CPU 1 does "printk("hello\n");" then instead of getting either
>
> 0 1 2 3 4 5 6 7 8 9
> hello
>
> or
>
> hello
> 0 1 2 3 4 5 6 7 8 9
>
> either of which would be fine, we may get
>
> 0 1 2 3 hello
> 4 5 6 7 8 9
>
> which I don't think is fine - obviously the example is somewhat
> trite, but with the real instances of things that build output for one
> line through multiple calls to printk, you can get unreadable garbage,
> if I read the code correctly ?
You read the code correctly, and it follows the intent just fine. When
doing the printk I don't believe you want to introduce any delay in the
output, since often the system is in deep shit by the time the printk
starts.
If you want buffering you can add it on a case-by-case basis, but in
general I don't believe you do want a delay, because the output might be
lost on a dying system. Prink works like output to stderr, character
buffered. I would think a change to anything this fundimental would be a
Linus decision, but I think it's correct as is.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/