Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 31 Aug 2021 12:05:25 +0900
From:   Sergey Senozhatsky <senozhatsky@chromium.org>
To:     Petr Mladek <pmladek@suse.com>
Cc:     John Ogness <john.ogness@linutronix.de>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk v1 06/10] printk: use seqcount_latch for
 console_seq
Message-ID: <YS2cdfN5/D1Jzelg@google.com>
References: <20210803131301.5588-1-john.ogness@linutronix.de>
 <20210803131301.5588-7-john.ogness@linutronix.de>
 <YQvWuzpAv1Tw/CoQ@alley>
 <87bl6bx68f.fsf@jogness.linutronix.de>
 <YQ1bsdh8PoLwBrnl@alley>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YQ1bsdh8PoLwBrnl@alley>
Precedence: bulk

On (21/08/06 17:56), Petr Mladek wrote:
> 
> A solution might be to implement a generic cycle that would use
> the right latched_seq and buffers. Something like:
> 
> enum console_mode {
> 	CONSOLE_MODE_NORMAL = 0,
> 	CONSOLE_MODE_ATOMIC,
> 	CONSOLE_MODE_ATOMIC_NMI,
> 	CONSOLE_MODE_REPLAY_ALL,
> 	CONSOLE_MODE_LAST
> };
> 
> struct console_mode_info
> {
> 	static char text[CONSOLE_LOG_MAX];
> 	static char ext_text[CONSOLE_EXT_LOG_MAX];
> 	static struct latched_seq seq;
> };

Seems to me like this wants to be part of struct console.

[..]

> Problems:
> 
>    a) The same line might be printed by more contexts.
>    b) per-console kthreads?
> 
> 
> Ad a) I am not sure if we could prevent duplicated lines when
>       the nested IRQ/NMI writes the same message that is just
>       being written by the outer context. But it should be
>       an acceptable corner case.
> 
> Ad b) Everything will get much more complicated with per-console
>       kthreads. We will need counters and buffers for each console
>       and each context.

Oh, yes, you are talking about per-console counters/buffers too.

> This is what I was able to come up before leaving for vacation. I am
> not sure if it is the best design/naming and it if it has a chance
> to work.
> 
> But it looks like a way how to re-use the same code in all modes.
> It might help to see what is the same and what is special about each
> mode.
> 
> 
> I would prefer to see something like this instead of the completely
> different code paths for atomic consoles that are proposed by 7th
> patch of this patchset.

I agree.