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

[Kay Sievers]

On Wed, May 9, 2012 at 3:50 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
> On Wed, 2012-05-09 at 11:38 +0200, Kay Sievers wrote:

> I think your premise is wrong for a couple of reasons.
>
> 1: printk content is not guaranteed to be stable.

Nobody talks about the content of the strings.

> Â 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.

Again, that's only what you make out of it.

My point is reliable log _storage_ and with that properly working, the
output _format_ gets as _reliable_ as possible. Continuation printk()
today is entirely unreliable, not only for the continuation users,
also for everybody else, because we merge randomly with atomic
printk() users.

We have (stupid ) scripts that diff dmesg after
supposed-to-be-harmless kernel changes to automatically spot problems.
You can see all the broken merges of continuation lines, and they also
affect lines which do simple and proper atomic printk()s. This is not
useful, and again it's the broken _logic_ of storage not the _content_
of the message.

> 2: There are _thousands_ of printks without prefix levels.

Right, and nobody is crazy enough to think we want to touch them all.

> Â 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.

Right, it's the annotation of an exception; not nice, but pretty
well-defined, and can be isolated from the non-exception by software
instead of a human.

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

Nobody talks about that in this very context. It is all about better
_reliability_ of the facility not about _content_.

The structured data, possibly attached to the log message, which
uniquely identifies the kernel device, is surely meant to be machine
readable, and no, I'm absolutely not giving up on that approach.

> 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.

I'm convinced, that we need something simpler than a new cookie logic.
It can work sure, but I doubt we really wants to change the code flow
of all the stuff.

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

Again, nobody talks about content of here.

But reliable context-aware facilities are almost never a bad idea. We
can certainly make printk() better without changing the whole source
tree.

You might not oppose to the heuristics and the "throw it all in a bag
an let's find out later" strategy, I certainly don't like it and think
it's very broken.

> 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.

It is all available through /dev/kmsg,

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/