All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
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: Re: [PATCH printk v5 0/8] printk: cleanup buffer handling
Date: Wed, 11 Jan 2023 16:36:37 +0100	[thread overview]
Message-ID: <Y77XhV0oLEyRqa2r@alley> (raw)
In-Reply-To: <Y7wue/a2Pz0hi2cJ@alley>

On Mon 2023-01-09 16:10:52, Petr Mladek wrote:
> On Mon 2023-01-09 11:13:52, John Ogness wrote:
> > Hi,
> > 
> > This is v5 of a series to cleanup console buffer handling and
> > prepare for code sharing with the upcoming threaded/atomic
> > consoles. v4 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.
> > 
> > Changes since v4:
> > 
> > - Make console_prepend_dropped() a NOP for !CONFIG_PRINTK to
> >   workaround compiler warnings.
> > 
> > - In devkmsg_read() use printk_get_next_message() for the wait
> >   condition instead of looping to retry the actual read.
> > 
> > - Add an argument @may_suppress to printk_get_next_message() so
> >   devkmsg_read() can specify that records should not be skipped
> >   based on loglevel.
> > 
> > John Ogness
> > 
> > [0] https://lore.kernel.org/lkml/20230105103735.880956-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
> 
> The series looks ready for linux-next from my POV.
> 
> I am going to push it into a new branch rework/buffers-cleanup within
> two days or so unless anyone speak against it.

JFYI, the patchset has been committed into printk/linux.git,
branch rework/buffers-cleanup.

It it intended for the next 6.3 merge window.

Best Regards,
Petr

      reply	other threads:[~2023-01-11 15:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 10:07 [PATCH printk v5 0/8] printk: cleanup buffer handling John Ogness
2023-01-09 10:07 ` [PATCH printk v5 1/8] printk: move size limit macros into internal.h John Ogness
2023-01-09 10:07 ` [PATCH printk v5 2/8] console: Use BIT() macros for @flags values John Ogness
2023-01-09 10:07 ` [PATCH printk v5 3/8] console: Document struct console John Ogness
2023-01-09 10:07 ` [PATCH printk v5 4/8] printk: introduce struct printk_buffers John Ogness
2023-01-09 10:07 ` [PATCH printk v5 5/8] printk: introduce printk_get_next_message() and printk_message John Ogness
2023-01-09 10:07 ` [PATCH printk v5 6/8] printk: introduce console_prepend_dropped() for dropped messages John Ogness
2023-01-09 14:12   ` Petr Mladek
2023-01-09 10:07 ` [PATCH printk v5 7/8] printk: use printk_buffers for devkmsg John Ogness
2023-01-09 14:23   ` Petr Mladek
2023-01-09 10:08 ` [PATCH printk v5 8/8] printk: adjust string limit macros John Ogness
2023-01-09 15:10 ` [PATCH printk v5 0/8] printk: cleanup buffer handling Petr Mladek
2023-01-11 15:36   ` Petr Mladek [this message]

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=Y77XhV0oLEyRqa2r@alley \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.