[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200819232632.13418-1-john.ogness@linutronix.de>
Date: Thu, 20 Aug 2020 01:32:27 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/5] printk: new log_cont implementation
Hello,
My recent series [0] to perform log_cont handling by the readers
was not received well, mainly because of the blank lines in the
output for existing dmesg and journalctl tools. This caused a
discussion about alternative methods of handling log_cont. This
RFC series is the result of that discussion.
Rather than storing individual log_cont parts into the ringbuffer,
this series will buffer the parts until flushed or the message is
complete (just as mainline does it now). The difference to mainline
is that a new API is used that allows the printk subsystem to
effectively track the caller while making use of separate
per-caller buffers.
The API is designed such that:
1. The API calls map clearly to the mainline log_cont calls. This
is important because all current log_cont users will need to
be updated.
2. The underlying implementation can be changed/improved at some
later time without requiring the code of log_cont users to
change (again).
The mainline log_cont syntax:
printk(KERN_INFO "text");
printk(KERN_CONT " continued");
printk(KERN_CONT "\n");
The new RFC log_cont syntax:
pr_cont_t c;
pr_cont_begin(&c, KERN_INFO "text");
pr_cont_append(&c, " continued");
pr_cont_end(&c);
Note that both methods can co-exist until all users of the old
mechanism have been converted over.
For this RFC series, 10KiB of memory are set aside to allow up to 10
simultaneous log_cont users. Obviously that might be adjusted based
on the number of CPUs or whatever.
The first patch implements the new log_cont mechanism. The following
4 patches convert existing log_cont user code, with each patch
taking on a more complex example.
This RFC series not only improves log_cont output generally, but
also addresses the lockless printk issue related to log_cont.
John Ogness
[0] https://lkml.kernel.org/r/20200717234818.8622-1-john.ogness@linutronix.de
John Ogness (5):
printk: implement pr_cont_t
sysrq: use pr_cont_t for cont messages
workqueue: use pr_cont_t for cont messages
locking/selftest: use pr_cont_t for cont messages
lockdep: use pr_cont_t for cont messages
based on next-20200819
drivers/tty/sysrq.c | 8 +-
include/linux/printk.h | 19 ++
kernel/locking/lockdep.c | 463 +++++++++++++++++++++++----------------
kernel/printk/printk.c | 137 ++++++++++++
kernel/workqueue.c | 71 +++---
lib/locking-selftest.c | 85 +++----
6 files changed, 519 insertions(+), 264 deletions(-)
--
2.20.1
Powered by blists - more mailing lists