Messages in this thread | | | Date | Thu, 19 Dec 2019 10:50:38 +0100 | From | Petr Mladek <> | Subject | Re: [RFC/PATCH] printk: Fix preferred console selection with multiple matches |
| |
On Mon 2019-12-16 11:09:33, Benjamin Herrenschmidt wrote: > On Wed, 2019-12-11 at 10:17 +0100, Petr Mladek wrote: > > The reverse search of list of console does not work for ttySX > > consoles because the number is omitted when matching. And the messages > > will appear only on the first matched serial console. There is > > a paragraph about this in the commit message of my patch. > > About that specific issue... > > I see indeed that 8250_core.c registers a "generic" console with index > -1 which will match whetever we hit first in the array. > > This is actually wrong isn't it ? Without any change such as what we've > been proposing, it means that an arch doing add_preferred_console of > any ttyS* will override anything on the command line, and it also means > that a command line with multiple ttyS entries will stop at the first > one, not the last one. > > IE. In both case the code will select a console that isn't > preferred_console... or am I missing something subtle ? > > So yes, fixing that will "regress" in the sense that it will change the > behaviour, but to make it match what's documented... am I wrong ? > > The question then becomes what's the most broken ? Changing the > behaviour that might have become expected or leaving the (alledgedly) > broken behaviour in place ?
I though the same. But then I found the following in Documentation/admin-guide/serial-console.rst
"If no console device is specified, the first device found capable of acting as a system console will be used. At this time, the system first looks for a VGA card and then for a serial port. So if you don't have a VGA card in your system the first serial port will automatically become the console."
In addition, there is the "documentation" how systemd handles serial console and login prompts, see http://0pointer.de/blog/projects/serial-console.html
I agree that the current behavior is wrong. I really would like to change it. But the result would be that some users will not get login prompt after a kernel update. I am afraid that we are blocked by the "do not break userspace" rule.
Best Regards, Petr
| |