From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: [PATCH printk v4 0/8] printk: cleanup buffer handling
Date: Thu, 5 Jan 2023 11:43:27 +0106 [thread overview]
Message-ID: <20230105103735.880956-1-john.ogness@linutronix.de> (raw)
Hi,
This is v4 of a series to cleanup console buffer handling and
prepare for code sharing with the upcoming threaded/atomic
consoles. v3 is here [0].
The main purpose of the series is to introduce two new lockless
functions to handle reading and formatting of printk messages. These
functions can then be used from any context, which is important for
the upcoming threaded/atomic consoles. The series also helps to
cleanup some of the internal printk interfaces and cleanly separate
formatting code from outputting code.
Some changes in this version were not part of the feedback. However,
from the discussions and examples I decided that some of the names
I had previously chosen were not appropriate. Particularly, structs,
variables, and functions should only use the "console_" prefix if it
is console-specific. Things that are used for general printk
processing should use a "printk_" prefix. This makes the diff to v3
rather large, even though the "real code" has only minor changes.
@Petr: Like with v3, this version uses a wrapper struct for the
message metadata to avoid clobbering. Making the message formatting
code robust enough to handle metadata clobbering was too complex
(particularly with the dropped tracking).
Changes since v3:
- Provide a detailed explanation in the commit message about why
message metadata is put into a wrapper struct instead of the
buffer struct.
- Reorder stack variable definitions so that static variables are at
the top and separated from non-static variables. IMHO it is
important to clearly see which of the variables are static.
- Drop a previous coding-style change from a line not related to
this series.
- In console_prepend_dropped() make sure the buffer is large enough
for the dropped message and at least PREFIX_MAX of the current
message.
- Define the PREFIX_MAX macro for !CONFIG_PRINTK in internal.h
because console_prepend_dropped() now needs it.
- Rename various functions, structs, fields, and macros:
console_get_next_message() -> printk_get_next_message()
struct console_buffers -> struct printk_buffers
struct console_message -> struct printk_message
console_message.cbufs -> printk_message.pbufs
console_message.outbuf_seq -> printk_message.seq
LOG_LINE_MAX -> PRINTKRB_RECORD_MAX
PREFIX_MAX -> PRINTK_PREFIX_MAX
CONSOLE_LOG_MAX and
CONSOLE_EXT_LOG_MAX -> PRINTK_MESSAGE_MAX
- Adjust the values of string limit macros. This is explained in
detail in the commit message.
- Replace @buf and @text_buf in struct devkmsg_user with struct
printk_buffers.
- Replace message formatting code in devkmsg_read() with
printk_get_next_message().
- Define all printk_message structs on the stack.
John Ogness
[0] https://lore.kernel.org/lkml/20221221202704.857925-1-john.ogness@linutronix.de
John Ogness (6):
printk: move size limit macros into internal.h
printk: introduce struct printk_buffers
printk: introduce printk_get_next_message() and printk_message
printk: introduce console_prepend_dropped() for dropped messages
printk: use printk_buffers for devkmsg
printk: adjust string limit macros
Thomas Gleixner (2):
console: Use BIT() macros for @flags values
console: Document struct console
include/linux/console.h | 100 +++++++++----
include/linux/printk.h | 2 -
kernel/printk/internal.h | 45 ++++++
kernel/printk/printk.c | 293 +++++++++++++++++++++++----------------
4 files changed, 288 insertions(+), 152 deletions(-)
base-commit: 6b2b0d839acaa84f05a77184370f793752e786e9
--
2.30.2
next reply other threads:[~2023-01-05 10:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 10:37 John Ogness [this message]
2023-01-05 10:37 ` [PATCH printk v4 1/8] printk: move size limit macros into internal.h John Ogness
2023-01-05 14:48 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 2/8] console: Use BIT() macros for @flags values John Ogness
2023-01-05 10:37 ` [PATCH printk v4 3/8] console: Document struct console John Ogness
2023-01-05 10:37 ` [PATCH printk v4 4/8] printk: introduce struct printk_buffers John Ogness
2023-01-05 15:06 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 5/8] printk: introduce printk_get_next_message() and printk_message John Ogness
2023-01-05 15:24 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 6/8] printk: introduce console_prepend_dropped() for dropped messages John Ogness
2023-01-05 16:17 ` Petr Mladek
2023-01-05 16:35 ` John Ogness
2023-01-06 9:34 ` Petr Mladek
2023-01-05 10:37 ` [PATCH printk v4 7/8] printk: use printk_buffers for devkmsg John Ogness
2023-01-05 12:14 ` John Ogness
2023-01-05 12:16 ` [PATCH printk v4 7/8 v2] " John Ogness
2023-01-06 10:39 ` Petr Mladek
2023-01-08 21:11 ` John Ogness
2023-01-05 10:37 ` [PATCH printk v4 8/8] printk: adjust string limit macros John Ogness
2023-01-06 11:11 ` Petr Mladek
2023-01-06 11:21 ` [PATCH printk v4 0/8] printk: cleanup buffer handling Petr Mladek
2023-01-07 8:18 ` John Ogness
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230105103735.880956-1-john.ogness@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).