Re: [RFC PATCH v5 0/3] printk: new ringbuffer implementation

[Eugeniu Rosca]

Hi John,

On Thu, Nov 28, 2019 at 02:58:32AM +0106, John Ogness wrote:
> Hello,
> 
> This is a follow-up RFC on the work to re-implement much of the
> core of printk. The threads for the previous RFC versions are
> here[0][1][2][3].
> 
> This RFC includes only the ringbuffer and a test module. This is
> a rewrite of the proposed ringbuffer, now based on the proof of
> concept[4] from Petr Mladek as agreed at the meeting[5] during
> LPC2019 in Lisbon.
> 
> [0] https://lkml.kernel.org/r/20190212143003.48446-1-john.ogness@xxxxxxxxxxxxx
> [1] https://lkml.kernel.org/r/20190607162349.18199-1-john.ogness@xxxxxxxxxxxxx
> [2] https://lkml.kernel.org/r/20190727013333.11260-1-john.ogness@xxxxxxxxxxxxx
> [3] https://lkml.kernel.org/r/20190807222634.1723-1-john.ogness@xxxxxxxxxxxxx
> [4] https://lkml.kernel.org/r/20190704103321.10022-1-pmladek@xxxxxxxx
> [5] https://lkml.kernel.org/r/87k1acz5rx.fsf@xxxxxxxxxxxxx
> 
> John Ogness (3):
>   printk-rb: new printk ringbuffer implementation (writer)
>   printk-rb: new printk ringbuffer implementation (reader)
>   printk-rb: add test module

As a follow-up to the discussion started in [*], I would like to stress
once again that it is extremely convenient to have the context of the
console drivers detached from the printk callers, particularly to
mitigate the issue described in [*].

I gave the test module from this series a try, by running it overnight
on R-Car H3ULCB, and spotted no issues whatsoever. I won't post any
signatures, as this is RFC, but I would be willing to do so for any
upcoming non-RFC series. Looking forward to that!

[*] https://lore.kernel.org/linux-serial/20200120230522.GA23636@xxxxxxxxxxxxxxxxxxxx/

-- 
Best Regards
Eugeniu Rosca