On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote:
> On Sun, Oct 23, 2016 at 2:22 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
> >
> > These changes have an interesting side-effect on sequences of printk()s that
> > lack proper continuation: they introduced a discrepancy between dmesg output
> > and the actual kernel output.
>
> Yes.
>
> So the "print vs log" handling is really really horrible. I cleaned up
> some of it, but left the really fundamental problems. I wanted to just
> rewrite it all, but didn't quite have the heart for it.
>
> The best solution by far would be to just not support KERN_CONT at
> all, but there's too many "silly details" things that keep it from
> being possible.
>
> The basic issue is that we have the line buffer that is used for
> continuations, and then the record buffer that is used for logging.
>
> And those two per se sound fairly easy to handle ("KERN_CONT means
> append to the line buffer, otherwise flush the line buffer and move to
> the record buffer").
>
> But what complicates things more is then the "console output", which
> has two issues:
>
> - it is done outside the locking regime for the line buffer and the
> record buffer.
>
> - it is done on _partial_ line buffers.
EOL KERN_<LEVEL> and thread interleaving still exists.
> It would be really quite easy to say "we don't print out
> continuation lines immediately, we just buffer them for 0.1s instead,
> and KERN_CONT only works for things that really happen more or less
> immediately".
Or use to a start/stop buffer (maybe via KERN_<LEVEL> and \n) with
PID/TIDs added to /dev/kmsg and that short-term timer to reassemble.
> Maybe that really is the right answer. Because the original cause of
> us having to bend over backwards in this case is really no longer
> there. And it would simplify printk a *lot*.
A timer might be a good idea, but perhaps Sergey and Petr might
have some interest in that too. (added to cc's)
