On (20/04/30 19:14), Alper Nebi Yasak wrote:
> Currently, add_preferred_console sets a preferred console, but doesn't
> actually change /dev/console to match it. That part is handled within
> register_device, where a newly registered console driver will be set as
> /dev/console if it matches the preferred console.
>
> However, if the relevant driver is already registered, the only way to
> set it as /dev/console is by un-registering and re-registering it.
Hmm. Preferred console selection is very fragile, there are too many
setups and workarounds that even minor tweaks introduce regressions
oftentimes.
We have, by the way, a pending patchset which changes the same
are - preferred console selection.
git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk.git
for-5.7-preferred-console
[..]
> An example is the xenfb_make_preferred_console() function:
>
> console_lock();
> for_each_console(c) {
> if (!strcmp(c->name, "tty") && c->index == 0)
> break;
> }
> console_unlock();
> if (c) {
> unregister_console(c);
> c->flags |= CON_CONSDEV;
> c->flags &= ~CON_PRINTBUFFER; /* don't print again */
> register_console(c);
> }
I didn't know about this code.
> The code above was introduced in commit 9e124fe16ff2 ("xen: Enable
> console tty by default in domU if it's not a dummy"). In short, it's aim
> is to set VT as the preferred console only after a working framebuffer
> is registered and thus VT is not the dummy device.
>
> This patch introduces an update_console_to_preferred function that
> handles the necessary /dev/console change. With this change, the example
> above can be replaced with:
>
> console_lock();
> add_preferred_console("tty", 0, NULL);
> update_console_to_preferred();
> console_unlock();
>
> More importantly, these two calls can be moved to vt.c in order to bump
> its priority when a non-dummy backend for it is introduced, solving that
> problem in general.
Let me take a look over the weekend.
-ss
