Re: [PATCH printk v3 00/15] printk/for-next

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,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexander Potapenko <glider@google.com>,
	Stephen Boyd <swboyd@chromium.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>, Helge Deller <deller@gmx.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Xiaoming Ni <nixiaoming@huawei.com>,
	Marco Elver <elver@google.com>, Wei Liu <wei.liu@kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Mark Brown <broonie@kernel.org>, Shawn Guo <shawn.guo@linaro.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	Wang Qing <wangqing@vivo.com>,
	rcu@vger.kernel.org
Subject: Re: [PATCH printk v3 00/15] printk/for-next
Date: Thu, 21 Apr 2022 17:08:43 +0206	[thread overview]
Message-ID: <8735i6h430.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20220421144025.GE11747@pathway.suse.cz>

On 2022-04-21, Petr Mladek <pmladek@suse.com> wrote:
> This series looks almost ready for linux-next. The only real
> problems are:
>
>    + Use allow_direct_printing() instead of
>      atomic_read(&printk_prefer_direct) in defer_console_output()
>
>    + "temporary" remove
>      console_lock_single_hold()/console_lock_single_release() and
>      use the full console_lock()/console_unlock() instead.
>
> The rest are few cosmetic issues.
>
> I would like to push this into linux-next ASAP so that we get some
> wider testing of this approach. I do not expect that we could find
> much more issues just by staring into the code ;-)
>
> Now, the question is whether I should wait for v4. Or whether
> I should put v3 into linux-next with a follow up patch doing
> the two above suggested changes. They are quite trivial.
>
> Anyway, if I pushed v3+fixup then I would replace it with v4, v5, ...
> once they are available. I just do not want to block testing because
> of cosmetic problems.

Even though the fixup may be straight-forward, it would be touching a
lot of lines and could potentially introduce new problems. I prefer you
wait for a v4 so that there is no mess to clean up.

I can post a v4 tomorrow (using option #1 from [0] as the
synchronization alternative).

John

[0] https://lore.kernel.org/r/875yn2h5ku.fsf@jogness.linutronix.de