Re: [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code

[John Ogness <john.ogness@linutronix.de>]

Hi Andrew,

On 2026-07-09, Andrew Murray <amurray@thegoodpenguin.co.uk> wrote:
>> The synchronous mode would rely on the driver being nbcon. I envision
>> something like this:
>
> Is it possible to apply synchronous mode for both nbcon and legacy
> consoles?

For !RT, legacy consoles are already "somewhat best effort"
synchronous. I really do not want to try to somehow improve on that. Our
goal is not to improve legacy, but to get rid of it.

> For the debugging case Benedikt suggested (is this the main
> use case for this feature?), it would be helpful if a developer could
> indicate a preference for synchronous mode without first determining
> the console type.

The developer is free to add ",sync" regardless if it is an nbcon or
not. My sync series (which I am currently testing) will simply give a
boot message that the console does not support sync mode.

>> ---- BEGIN SYNC IDEA ----
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index 2fe9a963c823a..beb5bb3c037b5 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -2456,6 +2456,8 @@ asmlinkage int vprintk_emit(int facility, int level,
>>
>>         if (ft.nbcon_atomic)
>>                 nbcon_atomic_flush_pending();
>> +       else if (have_nbcon_console_sync)
>> +               nbcon_atomic_flush_sync_pending();
>>
>>         if (ft.nbcon_offload)
>>                 nbcon_kthreads_wake();
>
> My interest in misusing (not proposing that as a solution) the
> emergency mode, is that the flush mode is nicely abstracted by
> printk_get_console_flush_type. Depending on how you trigger the sync
> mode, could printk_get_console_flush_type be expanded to look at a
> flag and return ft.legacy_direct, ft.legacy_offload or
> ft.nbcon_atomic_sync ?

Yes, I could do this, although it would only be "usable" for the
vprintk_emit() case. For the other two call sites:

nbcon_kthread_should_wakeup()
nbcon_device_release()

it would still need to be a @flags check because it is about a
particular console.

Of course, we could make printk_get_console_flush_type() per-console,
but that would be a considerable semantic change that would require
quite a bit of refactoring.

We can continue this conversation once I have posted my sync series.

John