On Wed, 29 Apr 2015 10:45:04 -0400 Tejun Heo <t...@kernel.org> wrote:
> printk log_buf keeps various metadata for each message including its > sequence number and timestamp. The metadata is currently available > only through /dev/kmsg and stripped out before passed onto console > drivers. We want this metadata to be available to console drivers too > so that console consumers can get full information including the > metadata and dictionary, which among other things can be used to > detect whether messages got lost in transit. > > This patch implements support for extended console drivers. Consoles > can indicate that they want extended messages by setting the new > CON_EXTENDED flag and they'll be fed messages formatted the same way > as /dev/kmsg. > > "<level>,<sequnum>,<timestamp>,<contflag>;<message text>\n" > > If extended consoles exist, in-kernel fragment assembly is disabled. > This ensures that all messages emitted to consoles have full metadata > including sequence number. The contflag carries enough information to > reassemble the fragments from the reader side trivially. Note that > this only affects /dev/kmsg. Regular console and /proc/kmsg outputs > are not affected by this change. > > * Extended message formatting for console drivers is enabled iff there > are registered extended consoles. > > * Comment describing /dev/kmsg message format updated to add missing > contflag field and help distinguishing variable from verbatim terms. So if I'm understanding this correctly, the /dev/kmsg output is altered (different cont handling) if some console registers with CON_EXTENDED (and there are no such consoles yet, so the patch is a no-op). If correct, this seems undesirable - registration of a CON_EXTENDED console collaterally damages the /dev/kmsg interface? If the user has an app which depends on the original /dev/kmsg format then they'll be wondered what-the-heck-just-happened? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
