On 2024-03-22, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * John Ogness <john.ogness@xxxxxxxxxxxxx> [240313 09:50]:
>> One nice thing that has risen from this is we are starting to see
>> exactly what the console lock is needed for. At this point I would say
>> its main function is synchronizing boot consoles with real
>> drivers. Which means we will not be able to remove the console lock
>> until we find a real solution to match boot consoles (which circumvent
>> the Linux driver model) with the real drivers.
>
> Would it help if earlycon handles all the boot consoles?
> Then just have the serial driver take over when it probes?
I think this would be very helpful. And it would also cleanup the boot
arguments. For example, we would no longer need the
architecture-specific arguments/options (such as "early_printk" and
"keep"). These architecture-specific arguments can be really
confusing. There have been so many times I see a developer cursing that
they can't get early debugging working, when I notice they are trying to
use "early_printk" on an arm64 system.
Browsing through
arch/x86/kernel/early_printk.c
arch/x86/boot/early_serial_console.c
you can see lots of examples of various early consoles and their special
tricks/hacks (such as pretending not to be a boot console when it really
is).
And pretty much every architecture has these. (git grep CON_BOOT)
Ideally it would be great if a console could register and say "taking
over for console X". Maybe with a new field:
struct console {
...
struct console *console_to_replace;
...
};
John Ogness
