On Thu, Apr 30, 2020 at 07:14:35PM +0300, 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. 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);
> }
>
> 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.
Even w/o looking into the code I believe it breaks more platforms than fixes
anything. It was not first time one tries to do something about preferred
consoles and it appeared to break working configurations.
I would wait for PRINTK maintainers to tell, but to me it sounds like papering
over the real issue which you don't understand (yet).
--
With Best Regards,
Andy Shevchenko
