lkml.org 
[lkml]   [2021]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH printk v1 06/10] printk: use seqcount_latch for console_seq
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.

\
 
 \ /
  Last update: 2021-08-31 05:06    [W:0.092 / U:1.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site