Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer

[Joe Perches <joe@perches.com>]

On Wed, 2012-05-09 at 11:38 +0200, Kay Sievers wrote:
> On Wed, May 9, 2012 at 5:52 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, May 8, 2012 at 4:14 AM, Kay Sievers <kay@vrfy.org> wrote:
> >>
> >> Yeah, we need to make sure, we never merge the (always racy)
> >> continuation printk() users with (non-racy) non-continuation users.
> >> Therefore KERN_CONT is required to suppress the newline and to merge the
> >> content with the earlier non-newline-terminated printk() line.
> >
> > Why?
> 
> The idea was: Prefixes are not used that often, but not using a prefix
> should not expose the user to wrongly get appended to an earlier
> non-terminated line of another thread.
> 
> The point was to limit the "risk" of wrong merges to users of
> continuation, and not to users which send ordinary "atomic" lines.

I think your premise is wrong for a couple of reasons.

1: printk content is not guaranteed to be stable.

   printk content should not be guaranteed to be stable.
   It'd make it difficult to simply add a new message
   or extend or correct an existing one.

2: There are _thousands_ of printks without prefix levels.

   KERN_CONT was always kind of a half-stupid idea.
   It's only real purpose is to designate message
   continuations but it never gave enough information to
   correctly coalesce the messages.

I think you need to give up on the idea that printk
output can be made to be machine readable.

If you really want to have users get complete and
not-interleaved messages you need to buffer partial
messages,  Whether or not printk message coalescing
needs to have a cookie or can be done well enough by
using call tree information as suggested by Andrew
Morton is tbd.

Changing printk semantics and trying to stabilize
printk message content are bad ideas though.

I think printk_emit is an OK idea.  Having a
per-subsystem notification mechanism, something
like an expanded ethtool is certainly useful.

Making the new additional content of printk_emit
discoverable would be useful.

Converting log_buf from circular to record oriented
and adding another binary header/descriptor to it
is a good idea too.

cheers, Joe