linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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