From: Alper Nebi Yasak <alpernebiyasak@gmail.com> To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jslaby@suse.com>, Petr Mladek <pmladek@suse.com>, linux-serial@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Arvind Sankar <nivedita@alum.mit.edu>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Daniel Vetter <daniel.vetter@ffwll.ch>, "David S. Miller" <davem@davemloft.net>, Eric Biggers <ebiggers@google.com>, Feng Tang <feng.tang@intel.com>, Grzegorz Halat <ghalat@redhat.com>, Lukas Wunner <lukas@wunner.de>, Nicolas Pitre <nico@fluxnic.net>, Sam Ravnborg <sam@ravnborg.org> Subject: Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Date: Fri, 1 May 2020 14:08:56 +0300 [thread overview] Message-ID: <818ba356-ba35-68de-b7bf-f145a89280f1@gmail.com> (raw) In-Reply-To: <20200501013044.GA288759@jagdpanzerIV.localdomain> On 01/05/2020 04:30, Sergey Senozhatsky wrote:> Well, if there is a "mandated console", then why would we prefer > any other console? From what I understand, the firmware provides serial console settings to be used as the preferred _serial_ console (where it would be OK to switch to graphical consoles later on) and the kernel currently understands that such a console should be the preferred _system_ console (always preferred over even graphical ones). By "mandated" I'm referring to the kernel's current behavior, not to (in my understanding) the firmware's intentions. Even if the firmware/specifications is really asking the kernel to (tell userspace programs to) always use the serial console instead of the framebuffer console, while on e.g. a laptop-like device intended to be used with a keyboard and display -- is that the correct thing to do? From the userspace, under the conditions: - CONFIG_VT_CONSOLE is enabled - There is a working graphics adapter and a display - There is no console argument given in the kernel command line I expect that: - tty0 is included in the /proc/consoles list [1] - tty0 is the preferred console and /dev/console refers to it [2] With SPCR both are false, and with stdout-path only the second is false. Again, I'm OK with these being false during earlier stages until graphics start working, but I'm arguing they should be true after then. In the patches I tried to keep these serial consoles still enabled and preferred during early stages of boot, by trying to switch to vt only after a real working graphical backend for it is initialized. I mean, if my expectations are unreasonable and the current kernel behaviour is considered correct, these patches would be conceptually wrong; so please tell me if I got anything right/wrong in all this. [1] From the descripion of CONFIG_VT_CONSOLE: > [...] If you answer Y here, a virtual terminal (the device used to > interact with a physical terminal) can be used as system console. > [...] you should say Y here unless you want the kernel messages be > output only to a serial port [...] and by "as a prerequisite of [2]" [2] From the descripion of CONFIG_VT_CONSOLE: > If you do say Y here, by default the currently visible virtual > terminal (/dev/tty0) will be used as system console. You can change > that with a kernel command line option such as "console=tty3" which > would use the third virtual terminal as system console. [...] I'm assuming "by default" here means "without console arguments" regardless of firmware requests. This paragraph (with small changes) is repeated on many other Kconfig descriptions (drivers/tty/serial/Kconfig, drivers/tty/serial/8250/Kconfig, arch/sparc/Kconfig from grepping for '/dev/tty0' on **/Kconfig). From Documentation/admin-guide/serial-console.rst: > You can specify multiple console= options on the kernel command line. > [...] > Note that you can only define one console per device type (serial, video). > > 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. and later on: > Note that if you boot without a ``console=`` option (or with > ``console=/dev/tty0``), ``/dev/console`` is the same as ``/dev/tty0``. > In that case everything will still work.
WARNING: multiple messages have this Message-ID (diff)
From: Alper Nebi Yasak <alpernebiyasak@gmail.com> To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Petr Mladek <pmladek@suse.com>, Feng Tang <feng.tang@intel.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Eric Biggers <ebiggers@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Nicolas Pitre <nico@fluxnic.net>, linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, Daniel Vetter <daniel.vetter@ffwll.ch>, Arvind Sankar <nivedita@alum.mit.edu>, Grzegorz Halat <ghalat@redhat.com>, linux-serial@vger.kernel.org, Jiri Slaby <jslaby@suse.com>, Lukas Wunner <lukas@wunner.de>, Andrew Morton <akpm@linux-foundation.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Sam Ravnborg <sam@ravnborg.org>, "David S. Miller" <davem@davemloft.net>, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Date: Fri, 1 May 2020 14:08:56 +0300 [thread overview] Message-ID: <818ba356-ba35-68de-b7bf-f145a89280f1@gmail.com> (raw) In-Reply-To: <20200501013044.GA288759@jagdpanzerIV.localdomain> On 01/05/2020 04:30, Sergey Senozhatsky wrote:> Well, if there is a "mandated console", then why would we prefer > any other console? From what I understand, the firmware provides serial console settings to be used as the preferred _serial_ console (where it would be OK to switch to graphical consoles later on) and the kernel currently understands that such a console should be the preferred _system_ console (always preferred over even graphical ones). By "mandated" I'm referring to the kernel's current behavior, not to (in my understanding) the firmware's intentions. Even if the firmware/specifications is really asking the kernel to (tell userspace programs to) always use the serial console instead of the framebuffer console, while on e.g. a laptop-like device intended to be used with a keyboard and display -- is that the correct thing to do? From the userspace, under the conditions: - CONFIG_VT_CONSOLE is enabled - There is a working graphics adapter and a display - There is no console argument given in the kernel command line I expect that: - tty0 is included in the /proc/consoles list [1] - tty0 is the preferred console and /dev/console refers to it [2] With SPCR both are false, and with stdout-path only the second is false. Again, I'm OK with these being false during earlier stages until graphics start working, but I'm arguing they should be true after then. In the patches I tried to keep these serial consoles still enabled and preferred during early stages of boot, by trying to switch to vt only after a real working graphical backend for it is initialized. I mean, if my expectations are unreasonable and the current kernel behaviour is considered correct, these patches would be conceptually wrong; so please tell me if I got anything right/wrong in all this. [1] From the descripion of CONFIG_VT_CONSOLE: > [...] If you answer Y here, a virtual terminal (the device used to > interact with a physical terminal) can be used as system console. > [...] you should say Y here unless you want the kernel messages be > output only to a serial port [...] and by "as a prerequisite of [2]" [2] From the descripion of CONFIG_VT_CONSOLE: > If you do say Y here, by default the currently visible virtual > terminal (/dev/tty0) will be used as system console. You can change > that with a kernel command line option such as "console=tty3" which > would use the third virtual terminal as system console. [...] I'm assuming "by default" here means "without console arguments" regardless of firmware requests. This paragraph (with small changes) is repeated on many other Kconfig descriptions (drivers/tty/serial/Kconfig, drivers/tty/serial/8250/Kconfig, arch/sparc/Kconfig from grepping for '/dev/tty0' on **/Kconfig). From Documentation/admin-guide/serial-console.rst: > You can specify multiple console= options on the kernel command line. > [...] > Note that you can only define one console per device type (serial, video). > > 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. and later on: > Note that if you boot without a ``console=`` option (or with > ``console=/dev/tty0``), ``/dev/console`` is the same as ``/dev/tty0``. > In that case everything will still work. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-01 11:09 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-30 16:14 [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Alper Nebi Yasak 2020-04-30 16:14 ` Alper Nebi Yasak 2020-04-30 16:14 ` [RFC PATCH v2 1/3] printk: Add function to set console to preferred console's driver Alper Nebi Yasak 2020-04-30 16:14 ` Alper Nebi Yasak 2020-04-30 16:46 ` Andy Shevchenko 2020-04-30 16:46 ` Andy Shevchenko 2020-05-01 1:44 ` Sergey Senozhatsky 2020-05-01 1:44 ` Sergey Senozhatsky 2020-05-01 11:48 ` Alper Nebi Yasak 2020-05-01 11:48 ` Alper Nebi Yasak 2020-05-13 5:35 ` Sergey Senozhatsky 2020-05-13 5:35 ` Sergey Senozhatsky 2020-05-24 10:01 ` Daniel Vetter 2020-05-24 10:01 ` Daniel Vetter 2020-04-30 16:14 ` [RFC PATCH v2 2/3] vt: Set as preferred console when a non-dummy backend is bound Alper Nebi Yasak 2020-04-30 16:14 ` Alper Nebi Yasak 2020-04-30 16:14 ` [RFC PATCH v2 3/3] printk: Preset tty0 as a pseudo-preferred console Alper Nebi Yasak 2020-04-30 16:14 ` Alper Nebi Yasak 2020-04-30 16:44 ` [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path Andy Shevchenko 2020-04-30 16:44 ` Andy Shevchenko 2020-04-30 19:32 ` Alper Nebi Yasak 2020-04-30 19:32 ` Alper Nebi Yasak 2020-05-01 1:30 ` Sergey Senozhatsky 2020-05-01 1:30 ` Sergey Senozhatsky 2020-05-01 11:08 ` Alper Nebi Yasak [this message] 2020-05-01 11:08 ` Alper Nebi Yasak 2020-05-01 13:16 ` Andy Shevchenko 2020-05-01 13:16 ` Andy Shevchenko 2020-05-01 15:07 ` Alper Nebi Yasak 2020-05-01 15:07 ` Alper Nebi Yasak 2020-05-13 14:37 ` Petr Mladek 2020-05-13 14:37 ` Petr Mladek 2020-05-13 22:22 ` Benjamin Herrenschmidt 2020-05-13 22:22 ` Benjamin Herrenschmidt 2020-05-15 19:27 ` Alper Nebi Yasak 2020-05-15 19:27 ` Alper Nebi Yasak 2020-05-25 13:04 ` Petr Mladek 2020-05-25 13:04 ` Petr Mladek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=818ba356-ba35-68de-b7bf-f145a89280f1@gmail.com \ --to=alpernebiyasak@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=benh@kernel.crashing.org \ --cc=daniel.vetter@ffwll.ch \ --cc=davem@davemloft.net \ --cc=ebiggers@google.com \ --cc=feng.tang@intel.com \ --cc=ghalat@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=jslaby@suse.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=lukas@wunner.de \ --cc=nico@fluxnic.net \ --cc=nivedita@alum.mit.edu \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=sam@ravnborg.org \ --cc=sergey.senozhatsky@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.