Messages in this thread | | | Subject | Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer | From | Joe Perches <> | Date | Wed, 09 May 2012 06:50:57 -0700 |
| |
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
| |