VT-less kernels, and /dev/console on x86

VT-less kernels, and /dev/console on x86

[nerdopolis]

Hi

I originally brought this up on linux-serial, but I think it makes more sense
that it's part of how printk console device selection works. Without VTs, while
most software is able to handle the situation, some userspace programs expect
/dev/console to still be responsive. Namely systemd. It calls isatty() against
/dev/console, and since /dev/console on VT-less systems currently defaults to
/dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
refuses to write log messages to it.

There doesn't seem to be a mailing list for printk, so I had to use
get_maintainer.pl. Hopefully this is correct


After some grepping and guessing and testing, and playing around Something like
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index a45d423ad10f..f94a4632aab0 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -384,9 +384,12 @@ config NULL_TTY
 
          In order to use this driver, you should redirect the console to this
          TTY, or boot the kernel with console=ttynull.
-
          If unsure, say N.
 
+config NULL_TTY_CONSOLE
+        bool "Supports /dev/ttynull as a console automatically"
+        depends on NULL_TTY && !VT_CONSOLE
+
 config VCC
        tristate "Sun Virtual Console Concentrator"
        depends on SUN_LDOMS
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index dddb15f48d59..c1554a789de8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3712,6 +3712,11 @@ void __init console_init(void)
        initcall_t call;
        initcall_entry_t *ce;
 
+#ifdef CONFIG_NULL_TTY_CONSOLE
+       if (!strstr(boot_command_line, "console="))
+               add_preferred_console("ttynull", 0, NULL);
+#endif
+
        /* Setup the default TTY line discipline. */
        n_tty_init();
 



seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
redundant, it is optional, so that it doesn't cause any changes to
configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
and for bootloader configs, it won't change any behavior if the kernel command
line has a console device specified

With ttynull as the console device, isatty() no longer fails on /dev/console,
systemd writes the log messages fine to /dev/console, and when Plymouth calls
TIOCCONS on its PTY, it is able to get the log messages.


Thanks

Re: VT-less kernels, and /dev/console on x86

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:
> Hi
> 
> I originally brought this up on linux-serial, but I think it makes more sense
> that it's part of how printk console device selection works. Without VTs, while
> most software is able to handle the situation, some userspace programs expect
> /dev/console to still be responsive. Namely systemd. It calls isatty() against
> /dev/console, and since /dev/console on VT-less systems currently defaults to
> /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> refuses to write log messages to it.
> 
> There doesn't seem to be a mailing list for printk, so I had to use
> get_maintainer.pl. Hopefully this is correct
> 
> 
> After some grepping and guessing and testing, and playing around Something like
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index a45d423ad10f..f94a4632aab0 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -384,9 +384,12 @@ config NULL_TTY
>  
>           In order to use this driver, you should redirect the console to this
>           TTY, or boot the kernel with console=ttynull.
> -
>           If unsure, say N.
>  
> +config NULL_TTY_CONSOLE
> +        bool "Supports /dev/ttynull as a console automatically"
> +        depends on NULL_TTY && !VT_CONSOLE
> +
>  config VCC
>         tristate "Sun Virtual Console Concentrator"
>         depends on SUN_LDOMS
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index dddb15f48d59..c1554a789de8 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3712,6 +3712,11 @@ void __init console_init(void)
>         initcall_t call;
>         initcall_entry_t *ce;
>  
> +#ifdef CONFIG_NULL_TTY_CONSOLE
> +       if (!strstr(boot_command_line, "console="))
> +               add_preferred_console("ttynull", 0, NULL);
> +#endif
> +
>         /* Setup the default TTY line discipline. */
>         n_tty_init();
>  
> 
> 
> 
> seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> redundant, it is optional, so that it doesn't cause any changes to
> configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> and for bootloader configs, it won't change any behavior if the kernel command
> line has a console device specified
> 
> With ttynull as the console device, isatty() no longer fails on /dev/console,
> systemd writes the log messages fine to /dev/console, and when Plymouth calls
> TIOCCONS on its PTY, it is able to get the log messages.

Then what does /dev/ttynull do other than just to satisfy systemd? I expect
it to be like /dev/null, though.

Confused...

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Saturday, August 17, 2024 9:07:21 PM EDT Bagas Sanjaya wrote:
> On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:
> > Hi
> > 
> > I originally brought this up on linux-serial, but I think it makes more sense
> > that it's part of how printk console device selection works. Without VTs, while
> > most software is able to handle the situation, some userspace programs expect
> > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > refuses to write log messages to it.
> > 
> > There doesn't seem to be a mailing list for printk, so I had to use
> > get_maintainer.pl. Hopefully this is correct
> > 
> > 
> > After some grepping and guessing and testing, and playing around Something like
> > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > index a45d423ad10f..f94a4632aab0 100644
> > --- a/drivers/tty/Kconfig
> > +++ b/drivers/tty/Kconfig
> > @@ -384,9 +384,12 @@ config NULL_TTY
> >  
> >           In order to use this driver, you should redirect the console to this
> >           TTY, or boot the kernel with console=ttynull.
> > -
> >           If unsure, say N.
> >  
> > +config NULL_TTY_CONSOLE
> > +        bool "Supports /dev/ttynull as a console automatically"
> > +        depends on NULL_TTY && !VT_CONSOLE
> > +
> >  config VCC
> >         tristate "Sun Virtual Console Concentrator"
> >         depends on SUN_LDOMS
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index dddb15f48d59..c1554a789de8 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> >         initcall_t call;
> >         initcall_entry_t *ce;
> >  
> > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > +       if (!strstr(boot_command_line, "console="))
> > +               add_preferred_console("ttynull", 0, NULL);
> > +#endif
> > +
> >         /* Setup the default TTY line discipline. */
> >         n_tty_init();
> >  
> > 
> > 
> > 
> > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > redundant, it is optional, so that it doesn't cause any changes to
> > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > and for bootloader configs, it won't change any behavior if the kernel command
> > line has a console device specified
> > 
> > With ttynull as the console device, isatty() no longer fails on /dev/console,
> > systemd writes the log messages fine to /dev/console, and when Plymouth calls
> > TIOCCONS on its PTY, it is able to get the log messages.
> 
> Then what does /dev/ttynull do other than just to satisfy systemd? I expect
> it to be like /dev/null, though.
> 
> Confused...
> 
> 
/dev/ttynull is the fake tty device that was added in ~2019, I guess it's kind
of like /dev/null, but certain terminal related IOCTLs work against it too,
like TCGETS, which is the probe isatty() uses.

https://lore.kernel.org/all/20190403113327.3628-1-vincent.whitchurch@axis.com/
the original thread for the addition of the ttynull driver explains it better
than I can.

The issue came up here https://github.com/systemd/systemd/pull/33690 before I
knew about the existence of this driver. I was getting the nice status messages
from systemd appearing on Plymouth when the QEMU had a virtual console attached
to /dev/ttyS0, but on real hardware, I was not seeing these status messages.


The thought is that when distributions eventually decide to go VT-less they are
not going to want to change the kernel boot options in the bootloader config to
force console=ttynull, and might want this to happen automatically.

Re: VT-less kernels, and /dev/console on x86

[Greg KH]

On Sat, Aug 17, 2024 at 10:31:17PM -0400, nerdopolis wrote:
> The thought is that when distributions eventually decide to go VT-less they are
> not going to want to change the kernel boot options in the bootloader config to
> force console=ttynull, and might want this to happen automatically.

If/when they want to do this, odds are a command line will be fine, or
they will build in ttynull properly into their kernels.

thanks,

greg k-h

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Sunday, August 18, 2024 1:12:58 AM EDT Greg KH wrote:
> On Sat, Aug 17, 2024 at 10:31:17PM -0400, nerdopolis wrote:
> > The thought is that when distributions eventually decide to go VT-less they are
> > not going to want to change the kernel boot options in the bootloader config to
> > force console=ttynull, and might want this to happen automatically.
> 
> If/when they want to do this, odds are a command line will be fine, or
> they will build in ttynull properly into their kernels.
> 
For new installs, I guess it would be fine, but for existing installs they
would have to script out the changes to /etc/default/grub, and/or however
systemd-boot handles default kernel command line arguments during the upgrade
process.

I couldn't get ttynull to be selected by default without the command line
without the console=ttynull, even when building it into the kernel (not as a
module) without the modification to printk.c
> thanks,
> 
> greg k-h
> 

Re: VT-less kernels, and /dev/console on x86

[Greg KH]

On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:
> Hi
> 
> I originally brought this up on linux-serial, but I think it makes more sense
> that it's part of how printk console device selection works. Without VTs, while
> most software is able to handle the situation, some userspace programs expect
> /dev/console to still be responsive. Namely systemd. It calls isatty() against
> /dev/console, and since /dev/console on VT-less systems currently defaults to
> /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> refuses to write log messages to it.
> 
> There doesn't seem to be a mailing list for printk, so I had to use
> get_maintainer.pl. Hopefully this is correct
> 
> 
> After some grepping and guessing and testing, and playing around Something like
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index a45d423ad10f..f94a4632aab0 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -384,9 +384,12 @@ config NULL_TTY
>  
>           In order to use this driver, you should redirect the console to this
>           TTY, or boot the kernel with console=ttynull.
> -
>           If unsure, say N.
>  
> +config NULL_TTY_CONSOLE
> +        bool "Supports /dev/ttynull as a console automatically"
> +        depends on NULL_TTY && !VT_CONSOLE
> +
>  config VCC
>         tristate "Sun Virtual Console Concentrator"
>         depends on SUN_LDOMS
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index dddb15f48d59..c1554a789de8 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3712,6 +3712,11 @@ void __init console_init(void)
>         initcall_t call;
>         initcall_entry_t *ce;
>  
> +#ifdef CONFIG_NULL_TTY_CONSOLE
> +       if (!strstr(boot_command_line, "console="))
> +               add_preferred_console("ttynull", 0, NULL);
> +#endif
> +
>         /* Setup the default TTY line discipline. */
>         n_tty_init();
>  
> 
> 
> 
> seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> redundant, it is optional, so that it doesn't cause any changes to
> configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> and for bootloader configs, it won't change any behavior if the kernel command
> line has a console device specified

What is wrong with just setting the kernel command line for this
instead?

thanks,

greg k-h

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:
> On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:
> > Hi
> > 
> > I originally brought this up on linux-serial, but I think it makes more sense
> > that it's part of how printk console device selection works. Without VTs, while
> > most software is able to handle the situation, some userspace programs expect
> > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > refuses to write log messages to it.
> > 
> > There doesn't seem to be a mailing list for printk, so I had to use
> > get_maintainer.pl. Hopefully this is correct
> > 
> > 
> > After some grepping and guessing and testing, and playing around Something like
> > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > index a45d423ad10f..f94a4632aab0 100644
> > --- a/drivers/tty/Kconfig
> > +++ b/drivers/tty/Kconfig
> > @@ -384,9 +384,12 @@ config NULL_TTY
> >  
> >           In order to use this driver, you should redirect the console to this
> >           TTY, or boot the kernel with console=ttynull.
> > -
> >           If unsure, say N.
> >  
> > +config NULL_TTY_CONSOLE
> > +        bool "Supports /dev/ttynull as a console automatically"
> > +        depends on NULL_TTY && !VT_CONSOLE
> > +
> >  config VCC
> >         tristate "Sun Virtual Console Concentrator"
> >         depends on SUN_LDOMS
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index dddb15f48d59..c1554a789de8 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> >         initcall_t call;
> >         initcall_entry_t *ce;
> >  
> > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > +       if (!strstr(boot_command_line, "console="))
> > +               add_preferred_console("ttynull", 0, NULL);
> > +#endif
> > +
> >         /* Setup the default TTY line discipline. */
> >         n_tty_init();
> >  
> > 
> > 
> > 
> > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > redundant, it is optional, so that it doesn't cause any changes to
> > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > and for bootloader configs, it won't change any behavior if the kernel command
> > line has a console device specified
> 
> What is wrong with just setting the kernel command line for this
> instead?
> 
When they eventually start shipping kernels without VTs, they will then have to
include a script in their upgrade process that runs

sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub

(Assuming they are using Grub)
> thanks,
> 
> greg k-h
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:
> > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:
> > > Hi
> > > 
> > > I originally brought this up on linux-serial, but I think it makes more sense
> > > that it's part of how printk console device selection works. Without VTs, while
> > > most software is able to handle the situation, some userspace programs expect
> > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > refuses to write log messages to it.
> > > 
> > > There doesn't seem to be a mailing list for printk, so I had to use
> > > get_maintainer.pl. Hopefully this is correct
> > > 
> > > 
> > > After some grepping and guessing and testing, and playing around Something like
> > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > index a45d423ad10f..f94a4632aab0 100644
> > > --- a/drivers/tty/Kconfig
> > > +++ b/drivers/tty/Kconfig
> > > @@ -384,9 +384,12 @@ config NULL_TTY
> > >  
> > >           In order to use this driver, you should redirect the console to this
> > >           TTY, or boot the kernel with console=ttynull.
> > > -
> > >           If unsure, say N.
> > >  
> > > +config NULL_TTY_CONSOLE
> > > +        bool "Supports /dev/ttynull as a console automatically"
> > > +        depends on NULL_TTY && !VT_CONSOLE
> > > +
> > >  config VCC
> > >         tristate "Sun Virtual Console Concentrator"
> > >         depends on SUN_LDOMS
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index dddb15f48d59..c1554a789de8 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > >         initcall_t call;
> > >         initcall_entry_t *ce;
> > >  
> > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > +       if (!strstr(boot_command_line, "console="))
> > > +               add_preferred_console("ttynull", 0, NULL);
> > > +#endif
> > > +
> > >         /* Setup the default TTY line discipline. */
> > >         n_tty_init();
> > >  
> > > 
> > > 
> > > 
> > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > redundant, it is optional, so that it doesn't cause any changes to
> > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > and for bootloader configs, it won't change any behavior if the kernel command
> > > line has a console device specified
> > 
> > What is wrong with just setting the kernel command line for this
> > instead?
> > 
> When they eventually start shipping kernels without VTs, they will then have to
> include a script in their upgrade process that runs
> 
> sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub
Ugh, I meant
sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
sorry
> 
> (Assuming they are using Grub)
> > thanks,
> > 
> > greg k-h
> > 
> 
> 
> 
> 
> 

Re: VT-less kernels, and /dev/console on x86

[Steven Rostedt]

On Sun, 18 Aug 2024 10:30:22 -0400
nerdopolis <bluescreen_avenger@verizon.net> wrote:

> On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > Hi
> > > > 
> > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > that it's part of how printk console device selection works. Without VTs, while
> > > > most software is able to handle the situation, some userspace programs expect
> > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > refuses to write log messages to it.
> > > > 
> > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > get_maintainer.pl. Hopefully this is correct
> > > > 
> > > > 
> > > > After some grepping and guessing and testing, and playing around Something like
> > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > index a45d423ad10f..f94a4632aab0 100644
> > > > --- a/drivers/tty/Kconfig
> > > > +++ b/drivers/tty/Kconfig
> > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > >  
> > > >           In order to use this driver, you should redirect the console to this
> > > >           TTY, or boot the kernel with console=ttynull.
> > > > -
> > > >           If unsure, say N.
> > > >  
> > > > +config NULL_TTY_CONSOLE
> > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > +
> > > >  config VCC
> > > >         tristate "Sun Virtual Console Concentrator"
> > > >         depends on SUN_LDOMS
> > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > index dddb15f48d59..c1554a789de8 100644
> > > > --- a/kernel/printk/printk.c
> > > > +++ b/kernel/printk/printk.c
> > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > >         initcall_t call;
> > > >         initcall_entry_t *ce;
> > > >  
> > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > +       if (!strstr(boot_command_line, "console="))
> > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > +#endif
> > > > +
> > > >         /* Setup the default TTY line discipline. */
> > > >         n_tty_init();
> > > >  
> > > > 
> > > > 
> > > > 
> > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > line has a console device specified  
> > > 
> > > What is wrong with just setting the kernel command line for this
> > > instead?
> > >   
> > When they eventually start shipping kernels without VTs, they will then have to
> > include a script in their upgrade process that runs
> > 
> > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> Ugh, I meant
> sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> sorry

If you can modify the kernel .config for this, can you just update:

  CONFIG_CMDLINE_BOOL=y
  CONFIG_CMDLINE="console=ttynull"

?

There's also bootconfig, that allows you to append command lines to the
kernel image. See CONFIG_BOOT_CONFIG and Documentation/admin-guide/bootconfig.rst

-- Steve

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> On Sun, 18 Aug 2024 10:30:22 -0400
> nerdopolis <bluescreen_avenger@verizon.net> wrote:
> 
> > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > Hi
> > > > > 
> > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > most software is able to handle the situation, some userspace programs expect
> > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > refuses to write log messages to it.
> > > > > 
> > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > get_maintainer.pl. Hopefully this is correct
> > > > > 
> > > > > 
> > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > --- a/drivers/tty/Kconfig
> > > > > +++ b/drivers/tty/Kconfig
> > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > >  
> > > > >           In order to use this driver, you should redirect the console to this
> > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > -
> > > > >           If unsure, say N.
> > > > >  
> > > > > +config NULL_TTY_CONSOLE
> > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > +
> > > > >  config VCC
> > > > >         tristate "Sun Virtual Console Concentrator"
> > > > >         depends on SUN_LDOMS
> > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > --- a/kernel/printk/printk.c
> > > > > +++ b/kernel/printk/printk.c
> > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > >         initcall_t call;
> > > > >         initcall_entry_t *ce;
> > > > >  
> > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > +#endif
> > > > > +
> > > > >         /* Setup the default TTY line discipline. */
> > > > >         n_tty_init();
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > line has a console device specified  
> > > > 
> > > > What is wrong with just setting the kernel command line for this
> > > > instead?
> > > >   
> > > When they eventually start shipping kernels without VTs, they will then have to
> > > include a script in their upgrade process that runs
> > > 
> > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > Ugh, I meant
> > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > sorry
> 
> If you can modify the kernel .config for this, can you just update:
> 
>   CONFIG_CMDLINE_BOOL=y
>   CONFIG_CMDLINE="console=ttynull"
> 
> ?
> 
That could work, I think. I'll have to see how that works when a different
console= is specified on the command line from the bootloader though, I am
thinking that if console=ttyS0 is then manually specified by a user, there will
be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
know if there are actual ramifications of that, or not...


I am not sure if real distributions would want this to be the answer I guess I
will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
although this gives me an idea..

Would something like this below be more acceptable? I didn't test it yet, but
just the theory. I am thinking that this could have more use to allow a
preferred to be set...

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index dddb15f48d59..c1554a789de8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3712,6 +3712,11 @@ void __init console_init(void)
 	initcall_t call;
 	initcall_entry_t *ce;
 
+#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
+       if (!strstr(boot_command_line, "console="))
+               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
+#endif
+
 	/* Setup the default TTY line discipline. */
 	n_tty_init();
 

> There's also bootconfig, that allows you to append command lines to the
> kernel image. See CONFIG_BOOT_CONFIG and Documentation/admin-guide/bootconfig.rst
> 
> -- Steve
> 

Re: VT-less kernels, and /dev/console on x86

[Petr Mladek]

On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > On Sun, 18 Aug 2024 10:30:22 -0400
> > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > 
> > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > Hi
> > > > > > 
> > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > refuses to write log messages to it.
> > > > > > 
> > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > 
> > > > > > 
> > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > --- a/drivers/tty/Kconfig
> > > > > > +++ b/drivers/tty/Kconfig
> > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > >  
> > > > > >           In order to use this driver, you should redirect the console to this
> > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > -
> > > > > >           If unsure, say N.
> > > > > >  
> > > > > > +config NULL_TTY_CONSOLE
> > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > +
> > > > > >  config VCC
> > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > >         depends on SUN_LDOMS
> > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > --- a/kernel/printk/printk.c
> > > > > > +++ b/kernel/printk/printk.c
> > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > >         initcall_t call;
> > > > > >         initcall_entry_t *ce;
> > > > > >  
> > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > +#endif
> > > > > > +
> > > > > >         /* Setup the default TTY line discipline. */
> > > > > >         n_tty_init();
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > line has a console device specified  
> > > > > 
> > > > > What is wrong with just setting the kernel command line for this
> > > > > instead?
> > > > >   
> > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > include a script in their upgrade process that runs
> > > > 
> > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > Ugh, I meant
> > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > sorry
> > 
> > If you can modify the kernel .config for this, can you just update:
> > 
> >   CONFIG_CMDLINE_BOOL=y
> >   CONFIG_CMDLINE="console=ttynull"
> > 
> > ?
> > 
> That could work, I think. I'll have to see how that works when a different
> console= is specified on the command line from the bootloader though, I am
> thinking that if console=ttyS0 is then manually specified by a user, there will
> be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> know if there are actual ramifications of that, or not...

I guess that it would register both consoles in this case.

> I am not sure if real distributions would want this to be the answer I guess I
> will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> although this gives me an idea..
> 
> Would something like this below be more acceptable? I didn't test it yet, but
> just the theory. I am thinking that this could have more use to allow a
> preferred to be set...
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index dddb15f48d59..c1554a789de8 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3712,6 +3712,11 @@ void __init console_init(void)
>  	initcall_t call;
>  	initcall_entry_t *ce;
>  
> +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> +       if (!strstr(boot_command_line, "console="))
> +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> +#endif
> +
>  	/* Setup the default TTY line discipline. */
>  	n_tty_init();

This is better. But it does not handle some situations. For example,
default console might also by defined by:

   + scpr, see acpi_parse_spcr()
   + device tree, see of_console_check()
   + netconsole=, it is hidden in init_netconsole()

I tried to handle this another way. The "ttynull" console was
added when /dev/console could not be opened in console_on_rootfs(),
see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
as a fallback when there is no console").

But it did not work well and we had to revert the change, see
the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
ttynull as a fallback when there is no console").

Another idea:

1. We could use the same trick as netconsole. I mean to use:

	ttynull_console.flags |= CON_ENABLED;

   to force register_console() to register the console even
   when it is not defined in the list of preferred consoles.

   It is a kind of hack. But it looks cleaner that adding
   ttynull console into the list of preferred consoles.


2. We need to decide whether the fallback to ttynull console
   is needed as late as possible. It should be done after
   all other drivers call register_console().

   I would do it in late_initcall_sync().


3. We need to detect when the fallback is needed. The check
   of /dev/console does not work, see
   the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
   ttynull as a fallback when there is no console").

   A solution might be to check if @console_list is empty.


Something like (not even compile tested):

diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
index 6b2f7208b564..7cd7ba2ec33c 100644
--- a/drivers/tty/ttynull.c
+++ b/drivers/tty/ttynull.c
@@ -59,6 +59,16 @@ static struct console ttynull_console = {
 	.device = ttynull_device,
 };
 
+void __init register_ttynull_console_force(void)
+{
+	if (!ttynull_driver)
+		return;
+
+	/* Force registration by setting the CON_ENABLED flag. */
+	ttynull_console.flags |= CON_ENABLED;
+	register_console(&ttynull_console);
+}
+
 static int __init ttynull_init(void)
 {
 	struct tty_driver *driver;
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 054c0e7784fd..004612e6fc7f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
 }
 late_initcall(printk_late_init);
 
+static int __init console_fallback(void)
+{
+	bool need_fallback = false;
+
+	console_list_lock();
+	/*
+	 * Make sure that there is a console which can be associated
+	 * with /dev/console
+	 */
+	if (hlist_empty(&console_list))
+		need_fallback = true;
+
+	console_list_unlock();
+
+	if (need_fallback)
+		register_ttynull_console_force();
+}
+late_initcall_sync(console_fallback);
+
 #if defined CONFIG_PRINTK
 /* If @con is specified, only wait for that console. Otherwise wait for all. */
 static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)



The above code would need some love to compile without
CONFIG_NULL_TTY.

Also it still might break some system/configuration where the default
console driver calls register_console() later.

We might need to update the check in register_console() and
call try_enable_default_console() even when ttynull console
is already registered as a fallback. We might even want
to unregister the ttynull console in this case.

Best Regards,
Petr

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > 
> > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > Hi
> > > > > > > 
> > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > refuses to write log messages to it.
> > > > > > > 
> > > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > > 
> > > > > > > 
> > > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > > --- a/drivers/tty/Kconfig
> > > > > > > +++ b/drivers/tty/Kconfig
> > > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > > >  
> > > > > > >           In order to use this driver, you should redirect the console to this
> > > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > > -
> > > > > > >           If unsure, say N.
> > > > > > >  
> > > > > > > +config NULL_TTY_CONSOLE
> > > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > > +
> > > > > > >  config VCC
> > > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > > >         depends on SUN_LDOMS
> > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > > --- a/kernel/printk/printk.c
> > > > > > > +++ b/kernel/printk/printk.c
> > > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > > >         initcall_t call;
> > > > > > >         initcall_entry_t *ce;
> > > > > > >  
> > > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > > +#endif
> > > > > > > +
> > > > > > >         /* Setup the default TTY line discipline. */
> > > > > > >         n_tty_init();
> > > > > > >  
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > > line has a console device specified  
> > > > > > 
> > > > > > What is wrong with just setting the kernel command line for this
> > > > > > instead?
> > > > > >   
> > > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > > include a script in their upgrade process that runs
> > > > > 
> > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > > Ugh, I meant
> > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > > sorry
> > > 
> > > If you can modify the kernel .config for this, can you just update:
> > > 
> > >   CONFIG_CMDLINE_BOOL=y
> > >   CONFIG_CMDLINE="console=ttynull"
> > > 
> > > ?
> > > 
> > That could work, I think. I'll have to see how that works when a different
> > console= is specified on the command line from the bootloader though, I am
> > thinking that if console=ttyS0 is then manually specified by a user, there will
> > be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> > know if there are actual ramifications of that, or not...
> 
> I guess that it would register both consoles in this case.
> 
> > I am not sure if real distributions would want this to be the answer I guess I
> > will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> > although this gives me an idea..
> > 
> > Would something like this below be more acceptable? I didn't test it yet, but
> > just the theory. I am thinking that this could have more use to allow a
> > preferred to be set...
> > 
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index dddb15f48d59..c1554a789de8 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> >  	initcall_t call;
> >  	initcall_entry_t *ce;
> >  
> > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > +       if (!strstr(boot_command_line, "console="))
> > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > +#endif
> > +
> >  	/* Setup the default TTY line discipline. */
> >  	n_tty_init();
> 
> This is better. But it does not handle some situations. For example,
> default console might also by defined by:
> 
>    + scpr, see acpi_parse_spcr()
>    + device tree, see of_console_check()
>    + netconsole=, it is hidden in init_netconsole()
> 
> I tried to handle this another way. The "ttynull" console was
> added when /dev/console could not be opened in console_on_rootfs(),
> see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> as a fallback when there is no console").
> 
> But it did not work well and we had to revert the change, see
> the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> ttynull as a fallback when there is no console").
> 
> Another idea:
> 
> 1. We could use the same trick as netconsole. I mean to use:
> 
> 	ttynull_console.flags |= CON_ENABLED;
> 
>    to force register_console() to register the console even
>    when it is not defined in the list of preferred consoles.
> 
>    It is a kind of hack. But it looks cleaner that adding
>    ttynull console into the list of preferred consoles.
> 
> 
> 2. We need to decide whether the fallback to ttynull console
>    is needed as late as possible. It should be done after
>    all other drivers call register_console().
> 
>    I would do it in late_initcall_sync().
> 
> 
> 3. We need to detect when the fallback is needed. The check
>    of /dev/console does not work, see
>    the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
>    ttynull as a fallback when there is no console").
> 
>    A solution might be to check if @console_list is empty.
> 
> 
> Something like (not even compile tested):
> 
> diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> index 6b2f7208b564..7cd7ba2ec33c 100644
> --- a/drivers/tty/ttynull.c
> +++ b/drivers/tty/ttynull.c
> @@ -59,6 +59,16 @@ static struct console ttynull_console = {
>  	.device = ttynull_device,
>  };
>  
> +void __init register_ttynull_console_force(void)
> +{
> +	if (!ttynull_driver)
> +		return;
> +
> +	/* Force registration by setting the CON_ENABLED flag. */
> +	ttynull_console.flags |= CON_ENABLED;
> +	register_console(&ttynull_console);
> +}
> +
>  static int __init ttynull_init(void)
>  {
>  	struct tty_driver *driver;
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 054c0e7784fd..004612e6fc7f 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
>  }
>  late_initcall(printk_late_init);
>  
> +static int __init console_fallback(void)
> +{
> +	bool need_fallback = false;
> +
> +	console_list_lock();
> +	/*
> +	 * Make sure that there is a console which can be associated
> +	 * with /dev/console
> +	 */
> +	if (hlist_empty(&console_list))
> +		need_fallback = true;
> +
> +	console_list_unlock();
> +
> +	if (need_fallback)
> +		register_ttynull_console_force();
> +}
> +late_initcall_sync(console_fallback);
> +
>  #if defined CONFIG_PRINTK
>  /* If @con is specified, only wait for that console. Otherwise wait for all. */
>  static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)
> 
> 
I got it to compile with

--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -513,9 +513,12 @@ extern int braille_register_console(struct console *, int index,
 extern int braille_unregister_console(struct console *);
 #ifdef CONFIG_TTY
 extern void console_sysfs_notify(void);
+extern void register_ttynull_console_force(void);
 #else
 static inline void console_sysfs_notify(void)
 { }
+static inline void register_ttynull_console_force(void)
+{ }
 #endif
 extern bool console_suspend_enabled;
 
and throwing a "return 0;" in console_fallback()

Seems like at least on x86 though, when I tested (CONFIG_VT_CONSOLE disabled),
the console is still ttyS0, even if I add "-serial none" to the QEMU VM.



I saw 757055ae8dedf5333af17b, but I feel like the intent is different, if I am
understanding that correctly, which I very well could not be, to me it looks
like it is using ttynull as a _last_ resort when all else fails, but x86 always
seems to have /dev/ttyS0's, unless I make changes before the serial consoles
are used.


My concerns are more about the distributions that have had /dev/console work
no matter what because of CONFIG_VT_CONSOLE. isatty() always returns true 
against /dev/console when enabled. When it is disabled, /dev/ttyS0 wins and now
software like systemd that logs there is now at the mercy of how /dev/ttyS0 is
physically connected or not for it to be able to log successfully.



One of my _other_ ideas was to in setup_arch() in arch/x86/kernel/setup.c add
the "add_preferred_console("ttynull", 0, NULL);" when CONFIG_NULL_TTY_CONSOLE
is enabled right above where it calls vgacon_register_screen() for this reason.

It worked, but it probably was not correct either...
> 
> The above code would need some love to compile without
> CONFIG_NULL_TTY.
> 
> Also it still might break some system/configuration where the default
> console driver calls register_console() later.
> 
> We might need to update the check in register_console() and
> call try_enable_default_console() even when ttynull console
> is already registered as a fallback. We might even want
> to unregister the ttynull console in this case.
> 
> Best Regards,
> Petr
> 

Re: VT-less kernels, and /dev/console on x86

[Petr Mladek]

On Wed 2024-08-21 13:12:03, nerdopolis wrote:
> On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> > On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > > 
> > > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > > Hi
> > > > > > > > 
> > > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > > refuses to write log messages to it.
> > > > > > > > 
> > > > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > > > 
> > > > > > > > 
> > > > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > > > --- a/drivers/tty/Kconfig
> > > > > > > > +++ b/drivers/tty/Kconfig
> > > > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > > > >  
> > > > > > > >           In order to use this driver, you should redirect the console to this
> > > > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > > > -
> > > > > > > >           If unsure, say N.
> > > > > > > >  
> > > > > > > > +config NULL_TTY_CONSOLE
> > > > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > > > +
> > > > > > > >  config VCC
> > > > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > > > >         depends on SUN_LDOMS
> > > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > > > --- a/kernel/printk/printk.c
> > > > > > > > +++ b/kernel/printk/printk.c
> > > > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > > > >         initcall_t call;
> > > > > > > >         initcall_entry_t *ce;
> > > > > > > >  
> > > > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > >         /* Setup the default TTY line discipline. */
> > > > > > > >         n_tty_init();
> > > > > > > >  
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > > > line has a console device specified  
> > > > > > > 
> > > > > > > What is wrong with just setting the kernel command line for this
> > > > > > > instead?
> > > > > > >   
> > > > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > > > include a script in their upgrade process that runs
> > > > > > 
> > > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > > > Ugh, I meant
> > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > > > sorry
> > > > 
> > > > If you can modify the kernel .config for this, can you just update:
> > > > 
> > > >   CONFIG_CMDLINE_BOOL=y
> > > >   CONFIG_CMDLINE="console=ttynull"
> > > > 
> > > > ?
> > > > 
> > > That could work, I think. I'll have to see how that works when a different
> > > console= is specified on the command line from the bootloader though, I am
> > > thinking that if console=ttyS0 is then manually specified by a user, there will
> > > be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> > > know if there are actual ramifications of that, or not...
> > 
> > I guess that it would register both consoles in this case.
> > 
> > > I am not sure if real distributions would want this to be the answer I guess I
> > > will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> > > although this gives me an idea..
> > > 
> > > Would something like this below be more acceptable? I didn't test it yet, but
> > > just the theory. I am thinking that this could have more use to allow a
> > > preferred to be set...
> > > 
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index dddb15f48d59..c1554a789de8 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > >  	initcall_t call;
> > >  	initcall_entry_t *ce;
> > >  
> > > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > > +       if (!strstr(boot_command_line, "console="))
> > > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > > +#endif
> > > +
> > >  	/* Setup the default TTY line discipline. */
> > >  	n_tty_init();
> > 
> > This is better. But it does not handle some situations. For example,
> > default console might also by defined by:
> > 
> >    + scpr, see acpi_parse_spcr()
> >    + device tree, see of_console_check()
> >    + netconsole=, it is hidden in init_netconsole()
> > 
> > I tried to handle this another way. The "ttynull" console was
> > added when /dev/console could not be opened in console_on_rootfs(),
> > see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> > as a fallback when there is no console").
> > 
> > But it did not work well and we had to revert the change, see
> > the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > ttynull as a fallback when there is no console").
> > 
> > Another idea:
> > 
> > 1. We could use the same trick as netconsole. I mean to use:
> > 
> > 	ttynull_console.flags |= CON_ENABLED;
> > 
> >    to force register_console() to register the console even
> >    when it is not defined in the list of preferred consoles.
> > 
> >    It is a kind of hack. But it looks cleaner that adding
> >    ttynull console into the list of preferred consoles.
> > 
> > 
> > 2. We need to decide whether the fallback to ttynull console
> >    is needed as late as possible. It should be done after
> >    all other drivers call register_console().
> > 
> >    I would do it in late_initcall_sync().
> > 
> > 
> > 3. We need to detect when the fallback is needed. The check
> >    of /dev/console does not work, see
> >    the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> >    ttynull as a fallback when there is no console").
> > 
> >    A solution might be to check if @console_list is empty.
> > 
> > 
> > Something like (not even compile tested):
> > 
> > diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> > index 6b2f7208b564..7cd7ba2ec33c 100644
> > --- a/drivers/tty/ttynull.c
> > +++ b/drivers/tty/ttynull.c
> > @@ -59,6 +59,16 @@ static struct console ttynull_console = {
> >  	.device = ttynull_device,
> >  };
> >  
> > +void __init register_ttynull_console_force(void)
> > +{
> > +	if (!ttynull_driver)
> > +		return;
> > +
> > +	/* Force registration by setting the CON_ENABLED flag. */
> > +	ttynull_console.flags |= CON_ENABLED;
> > +	register_console(&ttynull_console);
> > +}
> > +
> >  static int __init ttynull_init(void)
> >  {
> >  	struct tty_driver *driver;
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 054c0e7784fd..004612e6fc7f 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
> >  }
> >  late_initcall(printk_late_init);
> >  
> > +static int __init console_fallback(void)
> > +{
> > +	bool need_fallback = false;
> > +
> > +	console_list_lock();
> > +	/*
> > +	 * Make sure that there is a console which can be associated
> > +	 * with /dev/console
> > +	 */
> > +	if (hlist_empty(&console_list))
> > +		need_fallback = true;
> > +
> > +	console_list_unlock();
> > +
> > +	if (need_fallback)
> > +		register_ttynull_console_force();
> > +}
> > +late_initcall_sync(console_fallback);
> > +
> >  #if defined CONFIG_PRINTK
> >  /* If @con is specified, only wait for that console. Otherwise wait for all. */
> >  static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)
> > 
> > 
> I got it to compile with
> 
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -513,9 +513,12 @@ extern int braille_register_console(struct console *, int index,
>  extern int braille_unregister_console(struct console *);
>  #ifdef CONFIG_TTY
>  extern void console_sysfs_notify(void);
> +extern void register_ttynull_console_force(void);
>  #else
>  static inline void console_sysfs_notify(void)
>  { }
> +static inline void register_ttynull_console_force(void)
> +{ }
>  #endif
>  extern bool console_suspend_enabled;
>  
> and throwing a "return 0;" in console_fallback()
> 
> Seems like at least on x86 though, when I tested (CONFIG_VT_CONSOLE disabled),
> the console is still ttyS0, even if I add "-serial none" to the QEMU VM.
> 
> 
> 
> I saw 757055ae8dedf5333af17b, but I feel like the intent is different, if I am
> understanding that correctly, which I very well could not be, to me it looks
> like it is using ttynull as a _last_ resort when all else fails, but x86 always
> seems to have /dev/ttyS0's, unless I make changes before the serial consoles
> are used.
> 
> My concerns are more about the distributions that have had /dev/console work
> no matter what because of CONFIG_VT_CONSOLE. isatty() always returns true 
> against /dev/console when enabled. When it is disabled, /dev/ttyS0 wins and now
> software like systemd that logs there is now at the mercy of how /dev/ttyS0 is
> physically connected or not for it to be able to log successfully.

I see. I have misunderstood the original problem.

Hmm, historically, the kernel tries to enable any available console by
default. It makes some sense. One would expect that when there is a
device than the user should be able to access it and see the messages there.

If I get it correctly, you suggest to do not register serial port
when it is not physically connected. It makes some sense.

But I think that this should be implemented on the serial console layer.
It should not call register_console() when the port is not connected.

Plus, it would need the above patch which would register
ttynull_console driver as the final fallback. Otherwise, /dev/console
would not be backed by any device. Or we could update console_device()
to return the ttynull_driver as a fallback when there is no console
registered.

> One of my _other_ ideas was to in setup_arch() in arch/x86/kernel/setup.c add
> the "add_preferred_console("ttynull", 0, NULL);" when CONFIG_NULL_TTY_CONSOLE
> is enabled right above where it calls vgacon_register_screen() for this reason.
> 
> It worked, but it probably was not correct either...

IMHO, this is not acceptable for a generic kernel. The kernel should
try show the messages whenever possible. It should not ignore serial
consoles when they are available.

Also I am sure that the kernel is used on devices which only
have a serial console. Such a change would cause regression
there.

Best Regards,
Petr

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, August 22, 2024 6:05:19 AM EDT Petr Mladek wrote:
> On Wed 2024-08-21 13:12:03, nerdopolis wrote:
> > On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> > > On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > > > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > > > 
> > > > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > > > Hi
> > > > > > > > > 
> > > > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > > > refuses to write log messages to it.
> > > > > > > > > 
> > > > > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > > > > --- a/drivers/tty/Kconfig
> > > > > > > > > +++ b/drivers/tty/Kconfig
> > > > > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > > > > >  
> > > > > > > > >           In order to use this driver, you should redirect the console to this
> > > > > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > > > > -
> > > > > > > > >           If unsure, say N.
> > > > > > > > >  
> > > > > > > > > +config NULL_TTY_CONSOLE
> > > > > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > > > > +
> > > > > > > > >  config VCC
> > > > > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > > > > >         depends on SUN_LDOMS
> > > > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > > > > --- a/kernel/printk/printk.c
> > > > > > > > > +++ b/kernel/printk/printk.c
> > > > > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > > > > >         initcall_t call;
> > > > > > > > >         initcall_entry_t *ce;
> > > > > > > > >  
> > > > > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > > > > +#endif
> > > > > > > > > +
> > > > > > > > >         /* Setup the default TTY line discipline. */
> > > > > > > > >         n_tty_init();
> > > > > > > > >  
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > > > > line has a console device specified  
> > > > > > > > 
> > > > > > > > What is wrong with just setting the kernel command line for this
> > > > > > > > instead?
> > > > > > > >   
> > > > > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > > > > include a script in their upgrade process that runs
> > > > > > > 
> > > > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > > > > Ugh, I meant
> > > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > > > > sorry
> > > > > 
> > > > > If you can modify the kernel .config for this, can you just update:
> > > > > 
> > > > >   CONFIG_CMDLINE_BOOL=y
> > > > >   CONFIG_CMDLINE="console=ttynull"
> > > > > 
> > > > > ?
> > > > > 
> > > > That could work, I think. I'll have to see how that works when a different
> > > > console= is specified on the command line from the bootloader though, I am
> > > > thinking that if console=ttyS0 is then manually specified by a user, there will
> > > > be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> > > > know if there are actual ramifications of that, or not...
> > > 
> > > I guess that it would register both consoles in this case.
> > > 
> > > > I am not sure if real distributions would want this to be the answer I guess I
> > > > will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> > > > although this gives me an idea..
> > > > 
> > > > Would something like this below be more acceptable? I didn't test it yet, but
> > > > just the theory. I am thinking that this could have more use to allow a
> > > > preferred to be set...
> > > > 
> > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > index dddb15f48d59..c1554a789de8 100644
> > > > --- a/kernel/printk/printk.c
> > > > +++ b/kernel/printk/printk.c
> > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > >  	initcall_t call;
> > > >  	initcall_entry_t *ce;
> > > >  
> > > > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > > > +       if (!strstr(boot_command_line, "console="))
> > > > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > > > +#endif
> > > > +
> > > >  	/* Setup the default TTY line discipline. */
> > > >  	n_tty_init();
> > > 
> > > This is better. But it does not handle some situations. For example,
> > > default console might also by defined by:
> > > 
> > >    + scpr, see acpi_parse_spcr()
> > >    + device tree, see of_console_check()
> > >    + netconsole=, it is hidden in init_netconsole()
> > > 
> > > I tried to handle this another way. The "ttynull" console was
> > > added when /dev/console could not be opened in console_on_rootfs(),
> > > see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> > > as a fallback when there is no console").
> > > 
> > > But it did not work well and we had to revert the change, see
> > > the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > > ttynull as a fallback when there is no console").
> > > 
> > > Another idea:
> > > 
> > > 1. We could use the same trick as netconsole. I mean to use:
> > > 
> > > 	ttynull_console.flags |= CON_ENABLED;
> > > 
> > >    to force register_console() to register the console even
> > >    when it is not defined in the list of preferred consoles.
> > > 
> > >    It is a kind of hack. But it looks cleaner that adding
> > >    ttynull console into the list of preferred consoles.
> > > 
> > > 
> > > 2. We need to decide whether the fallback to ttynull console
> > >    is needed as late as possible. It should be done after
> > >    all other drivers call register_console().
> > > 
> > >    I would do it in late_initcall_sync().
> > > 
> > > 
> > > 3. We need to detect when the fallback is needed. The check
> > >    of /dev/console does not work, see
> > >    the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > >    ttynull as a fallback when there is no console").
> > > 
> > >    A solution might be to check if @console_list is empty.
> > > 
> > > 
> > > Something like (not even compile tested):
> > > 
> > > diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> > > index 6b2f7208b564..7cd7ba2ec33c 100644
> > > --- a/drivers/tty/ttynull.c
> > > +++ b/drivers/tty/ttynull.c
> > > @@ -59,6 +59,16 @@ static struct console ttynull_console = {
> > >  	.device = ttynull_device,
> > >  };
> > >  
> > > +void __init register_ttynull_console_force(void)
> > > +{
> > > +	if (!ttynull_driver)
> > > +		return;
> > > +
> > > +	/* Force registration by setting the CON_ENABLED flag. */
> > > +	ttynull_console.flags |= CON_ENABLED;
> > > +	register_console(&ttynull_console);
> > > +}
> > > +
> > >  static int __init ttynull_init(void)
> > >  {
> > >  	struct tty_driver *driver;
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index 054c0e7784fd..004612e6fc7f 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
> > >  }
> > >  late_initcall(printk_late_init);
> > >  
> > > +static int __init console_fallback(void)
> > > +{
> > > +	bool need_fallback = false;
> > > +
> > > +	console_list_lock();
> > > +	/*
> > > +	 * Make sure that there is a console which can be associated
> > > +	 * with /dev/console
> > > +	 */
> > > +	if (hlist_empty(&console_list))
> > > +		need_fallback = true;
> > > +
> > > +	console_list_unlock();
> > > +
> > > +	if (need_fallback)
> > > +		register_ttynull_console_force();
> > > +}
> > > +late_initcall_sync(console_fallback);
> > > +
> > >  #if defined CONFIG_PRINTK
> > >  /* If @con is specified, only wait for that console. Otherwise wait for all. */
> > >  static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)
> > > 
> > > 
> > I got it to compile with
> > 
> > --- a/include/linux/console.h
> > +++ b/include/linux/console.h
> > @@ -513,9 +513,12 @@ extern int braille_register_console(struct console *, int index,
> >  extern int braille_unregister_console(struct console *);
> >  #ifdef CONFIG_TTY
> >  extern void console_sysfs_notify(void);
> > +extern void register_ttynull_console_force(void);
> >  #else
> >  static inline void console_sysfs_notify(void)
> >  { }
> > +static inline void register_ttynull_console_force(void)
> > +{ }
> >  #endif
> >  extern bool console_suspend_enabled;
> >  
> > and throwing a "return 0;" in console_fallback()
> > 
> > Seems like at least on x86 though, when I tested (CONFIG_VT_CONSOLE disabled),
> > the console is still ttyS0, even if I add "-serial none" to the QEMU VM.
> > 
> > 
> > 
> > I saw 757055ae8dedf5333af17b, but I feel like the intent is different, if I am
> > understanding that correctly, which I very well could not be, to me it looks
> > like it is using ttynull as a _last_ resort when all else fails, but x86 always
> > seems to have /dev/ttyS0's, unless I make changes before the serial consoles
> > are used.
> > 
> > My concerns are more about the distributions that have had /dev/console work
> > no matter what because of CONFIG_VT_CONSOLE. isatty() always returns true 
> > against /dev/console when enabled. When it is disabled, /dev/ttyS0 wins and now
> > software like systemd that logs there is now at the mercy of how /dev/ttyS0 is
> > physically connected or not for it to be able to log successfully.
> 
> I see. I have misunderstood the original problem.
> 
> Hmm, historically, the kernel tries to enable any available console by
> default. It makes some sense. One would expect that when there is a
> device than the user should be able to access it and see the messages there.
> 
> If I get it correctly, you suggest to do not register serial port
> when it is not physically connected. It makes some sense.
> 
Hmm, now that might work, and is a good idea...
> But I think that this should be implemented on the serial console layer.
> It should not call register_console() when the port is not connected.
> 
> Plus, it would need the above patch which would register
> ttynull_console driver as the final fallback. Otherwise, /dev/console
> would not be backed by any device. Or we could update console_device()
> to return the ttynull_driver as a fallback when there is no console
> registered.
> 
> > One of my _other_ ideas was to in setup_arch() in arch/x86/kernel/setup.c add
> > the "add_preferred_console("ttynull", 0, NULL);" when CONFIG_NULL_TTY_CONSOLE
> > is enabled right above where it calls vgacon_register_screen() for this reason.
> > 
> > It worked, but it probably was not correct either...
> 
> IMHO, this is not acceptable for a generic kernel. The kernel should
> try show the messages whenever possible. It should not ignore serial
> consoles when they are available.
> 
Makes sense, on many desktop distros, the logging was not going to physical
hardware because of CONFIG_VT_CONSOLE being enabled, but I understand there are
many different types of embedded devices though.

Which is why my first thought was a new CONFIG_NULL_TTY_CONSOLE option that
would be disabled by default, but when _enabled_ (Trading CONFIG_VT_CONSOLE for
it), the behaviour could be the same on the serial ports,at least on x86, when it adds ttynull as a preferred console...

like:
#if defined(CONFIG_NULL_TTY_CONSOLE)
	if (!efi_enabled(EFI_BOOT) || (efi_mem_type(0xa0000) != EFI_CONVENTIONAL_MEMORY))
		add_preferred_console("ttynull", 0, NULL);
#endif

in arch/x86/kernel/setup.c to mimic I _think_ about where the VT console would
have been registered, and in the same conditions...

(this would only work in x86 though...)
> Also I am sure that the kernel is used on devices which only
> have a serial console. Such a change would cause regression
> there.
> 
> Best Regards,
> Petr
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, August 22, 2024 8:49:05 AM EDT nerdopolis wrote:
> On Thursday, August 22, 2024 6:05:19 AM EDT Petr Mladek wrote:
> > On Wed 2024-08-21 13:12:03, nerdopolis wrote:
> > > On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> > > > On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > > > > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > > > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > > > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > > > > 
> > > > > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > > > > Hi
> > > > > > > > > > 
> > > > > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > > > > refuses to write log messages to it.
> > > > > > > > > > 
> > > > > > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > > > > > --- a/drivers/tty/Kconfig
> > > > > > > > > > +++ b/drivers/tty/Kconfig
> > > > > > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > > > > > >  
> > > > > > > > > >           In order to use this driver, you should redirect the console to this
> > > > > > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > > > > > -
> > > > > > > > > >           If unsure, say N.
> > > > > > > > > >  
> > > > > > > > > > +config NULL_TTY_CONSOLE
> > > > > > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > > > > > +
> > > > > > > > > >  config VCC
> > > > > > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > > > > > >         depends on SUN_LDOMS
> > > > > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > > > > > --- a/kernel/printk/printk.c
> > > > > > > > > > +++ b/kernel/printk/printk.c
> > > > > > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > > > > > >         initcall_t call;
> > > > > > > > > >         initcall_entry_t *ce;
> > > > > > > > > >  
> > > > > > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > >         /* Setup the default TTY line discipline. */
> > > > > > > > > >         n_tty_init();
> > > > > > > > > >  
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > > > > > line has a console device specified  
> > > > > > > > > 
> > > > > > > > > What is wrong with just setting the kernel command line for this
> > > > > > > > > instead?
> > > > > > > > >   
> > > > > > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > > > > > include a script in their upgrade process that runs
> > > > > > > > 
> > > > > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > > > > > Ugh, I meant
> > > > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > > > > > sorry
> > > > > > 
> > > > > > If you can modify the kernel .config for this, can you just update:
> > > > > > 
> > > > > >   CONFIG_CMDLINE_BOOL=y
> > > > > >   CONFIG_CMDLINE="console=ttynull"
> > > > > > 
> > > > > > ?
> > > > > > 
> > > > > That could work, I think. I'll have to see how that works when a different
> > > > > console= is specified on the command line from the bootloader though, I am
> > > > > thinking that if console=ttyS0 is then manually specified by a user, there will
> > > > > be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> > > > > know if there are actual ramifications of that, or not...
> > > > 
> > > > I guess that it would register both consoles in this case.
> > > > 
> > > > > I am not sure if real distributions would want this to be the answer I guess I
> > > > > will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> > > > > although this gives me an idea..
> > > > > 
> > > > > Would something like this below be more acceptable? I didn't test it yet, but
> > > > > just the theory. I am thinking that this could have more use to allow a
> > > > > preferred to be set...
> > > > > 
> > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > --- a/kernel/printk/printk.c
> > > > > +++ b/kernel/printk/printk.c
> > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > >  	initcall_t call;
> > > > >  	initcall_entry_t *ce;
> > > > >  
> > > > > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > > > > +#endif
> > > > > +
> > > > >  	/* Setup the default TTY line discipline. */
> > > > >  	n_tty_init();
> > > > 
> > > > This is better. But it does not handle some situations. For example,
> > > > default console might also by defined by:
> > > > 
> > > >    + scpr, see acpi_parse_spcr()
> > > >    + device tree, see of_console_check()
> > > >    + netconsole=, it is hidden in init_netconsole()
> > > > 
> > > > I tried to handle this another way. The "ttynull" console was
> > > > added when /dev/console could not be opened in console_on_rootfs(),
> > > > see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> > > > as a fallback when there is no console").
> > > > 
> > > > But it did not work well and we had to revert the change, see
> > > > the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > > > ttynull as a fallback when there is no console").
> > > > 
> > > > Another idea:
> > > > 
> > > > 1. We could use the same trick as netconsole. I mean to use:
> > > > 
> > > > 	ttynull_console.flags |= CON_ENABLED;
> > > > 
> > > >    to force register_console() to register the console even
> > > >    when it is not defined in the list of preferred consoles.
> > > > 
> > > >    It is a kind of hack. But it looks cleaner that adding
> > > >    ttynull console into the list of preferred consoles.
> > > > 
> > > > 
> > > > 2. We need to decide whether the fallback to ttynull console
> > > >    is needed as late as possible. It should be done after
> > > >    all other drivers call register_console().
> > > > 
> > > >    I would do it in late_initcall_sync().
> > > > 
> > > > 
> > > > 3. We need to detect when the fallback is needed. The check
> > > >    of /dev/console does not work, see
> > > >    the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > > >    ttynull as a fallback when there is no console").
> > > > 
> > > >    A solution might be to check if @console_list is empty.
> > > > 
> > > > 
> > > > Something like (not even compile tested):
> > > > 
> > > > diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> > > > index 6b2f7208b564..7cd7ba2ec33c 100644
> > > > --- a/drivers/tty/ttynull.c
> > > > +++ b/drivers/tty/ttynull.c
> > > > @@ -59,6 +59,16 @@ static struct console ttynull_console = {
> > > >  	.device = ttynull_device,
> > > >  };
> > > >  
> > > > +void __init register_ttynull_console_force(void)
> > > > +{
> > > > +	if (!ttynull_driver)
> > > > +		return;
> > > > +
> > > > +	/* Force registration by setting the CON_ENABLED flag. */
> > > > +	ttynull_console.flags |= CON_ENABLED;
> > > > +	register_console(&ttynull_console);
> > > > +}
> > > > +
> > > >  static int __init ttynull_init(void)
> > > >  {
> > > >  	struct tty_driver *driver;
> > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > index 054c0e7784fd..004612e6fc7f 100644
> > > > --- a/kernel/printk/printk.c
> > > > +++ b/kernel/printk/printk.c
> > > > @@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
> > > >  }
> > > >  late_initcall(printk_late_init);
> > > >  
> > > > +static int __init console_fallback(void)
> > > > +{
> > > > +	bool need_fallback = false;
> > > > +
> > > > +	console_list_lock();
> > > > +	/*
> > > > +	 * Make sure that there is a console which can be associated
> > > > +	 * with /dev/console
> > > > +	 */
> > > > +	if (hlist_empty(&console_list))
> > > > +		need_fallback = true;
> > > > +
> > > > +	console_list_unlock();
> > > > +
> > > > +	if (need_fallback)
> > > > +		register_ttynull_console_force();
> > > > +}
> > > > +late_initcall_sync(console_fallback);
> > > > +
> > > >  #if defined CONFIG_PRINTK
> > > >  /* If @con is specified, only wait for that console. Otherwise wait for all. */
> > > >  static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)
> > > > 
> > > > 
> > > I got it to compile with
> > > 
> > > --- a/include/linux/console.h
> > > +++ b/include/linux/console.h
> > > @@ -513,9 +513,12 @@ extern int braille_register_console(struct console *, int index,
> > >  extern int braille_unregister_console(struct console *);
> > >  #ifdef CONFIG_TTY
> > >  extern void console_sysfs_notify(void);
> > > +extern void register_ttynull_console_force(void);
> > >  #else
> > >  static inline void console_sysfs_notify(void)
> > >  { }
> > > +static inline void register_ttynull_console_force(void)
> > > +{ }
> > >  #endif
> > >  extern bool console_suspend_enabled;
> > >  
> > > and throwing a "return 0;" in console_fallback()
> > > 
> > > Seems like at least on x86 though, when I tested (CONFIG_VT_CONSOLE disabled),
> > > the console is still ttyS0, even if I add "-serial none" to the QEMU VM.
> > > 
> > > 
> > > 
> > > I saw 757055ae8dedf5333af17b, but I feel like the intent is different, if I am
> > > understanding that correctly, which I very well could not be, to me it looks
> > > like it is using ttynull as a _last_ resort when all else fails, but x86 always
> > > seems to have /dev/ttyS0's, unless I make changes before the serial consoles
> > > are used.
> > > 
> > > My concerns are more about the distributions that have had /dev/console work
> > > no matter what because of CONFIG_VT_CONSOLE. isatty() always returns true 
> > > against /dev/console when enabled. When it is disabled, /dev/ttyS0 wins and now
> > > software like systemd that logs there is now at the mercy of how /dev/ttyS0 is
> > > physically connected or not for it to be able to log successfully.
> > 
> > I see. I have misunderstood the original problem.
> > 
> > Hmm, historically, the kernel tries to enable any available console by
> > default. It makes some sense. One would expect that when there is a
> > device than the user should be able to access it and see the messages there.
> > 
> > If I get it correctly, you suggest to do not register serial port
> > when it is not physically connected. It makes some sense.
> > 
> Hmm, now that might work, and is a good idea...
Although now that I think about it, could this cause unintended behavior on
some hardware? Or folks that might plug in the serial cable after booting for
whatever reason?

I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
this option. That could allow /dev/console will still work the same way for
user space logging, while disabling vgacon and fbcon.

And it could still be overridden by console=ttyS0, which I think is needed
anyway if you have CONFIG_VT_CONSOLE enabled
> > But I think that this should be implemented on the serial console layer.
> > It should not call register_console() when the port is not connected.
> > 
> > Plus, it would need the above patch which would register
> > ttynull_console driver as the final fallback. Otherwise, /dev/console
> > would not be backed by any device. Or we could update console_device()
> > to return the ttynull_driver as a fallback when there is no console
> > registered.
> > 
> > > One of my _other_ ideas was to in setup_arch() in arch/x86/kernel/setup.c add
> > > the "add_preferred_console("ttynull", 0, NULL);" when CONFIG_NULL_TTY_CONSOLE
> > > is enabled right above where it calls vgacon_register_screen() for this reason.
> > > 
> > > It worked, but it probably was not correct either...
> > 
> > IMHO, this is not acceptable for a generic kernel. The kernel should
> > try show the messages whenever possible. It should not ignore serial
> > consoles when they are available.
> > 
> Makes sense, on many desktop distros, the logging was not going to physical
> hardware because of CONFIG_VT_CONSOLE being enabled, but I understand there are
> many different types of embedded devices though.
> 
> Which is why my first thought was a new CONFIG_NULL_TTY_CONSOLE option that
> would be disabled by default, but when _enabled_ (Trading CONFIG_VT_CONSOLE for
> it), the behaviour could be the same on the serial ports,at least on x86, when it adds ttynull as a preferred console...
> 
> like:
> #if defined(CONFIG_NULL_TTY_CONSOLE)
> 	if (!efi_enabled(EFI_BOOT) || (efi_mem_type(0xa0000) != EFI_CONVENTIONAL_MEMORY))
> 		add_preferred_console("ttynull", 0, NULL);
> #endif
> 
> in arch/x86/kernel/setup.c to mimic I _think_ about where the VT console would
> have been registered, and in the same conditions...
> 
> (this would only work in x86 though...)
> > Also I am sure that the kernel is used on devices which only
> > have a serial console. Such a change would cause regression
> > there.
> > 
> > Best Regards,
> > Petr
> > 
> 
> 

Re: VT-less kernels, and /dev/console on x86

[Willy Tarreau]

On Tue, Aug 27, 2024 at 08:53:49AM -0400, nerdopolis wrote:
> > > If I get it correctly, you suggest to do not register serial port
> > > when it is not physically connected. It makes some sense.
> > > 
> > Hmm, now that might work, and is a good idea...
> Although now that I think about it, could this cause unintended behavior on
> some hardware? Or folks that might plug in the serial cable after booting for
> whatever reason?

The *vast* majority of serial ports spend their time non-connected, and
are only used to connect to the equipment at runtime, to recover a lost
access, or to connect locally to it during operations. What is proposed
above scares me a little bit:
  - PC-like serial ports (DB-9) support hardware flow control using the
    RTS/CTS lines and are expected to be instantly usable when connecting
    something to them. The presence of a cable is detectable, though many
    will just have a local loop (CTS-RTS, DCD-DTR-DSR) and will in fact
    only detect that the connector is plugged in. Some don't even connect
    them, and turn off HW flow control.

  - many boards don't even have hardware flow control and only provide
    the usual 3-4 pins (GND, TX, RX and optional VCC). These ones will
    never be detected as "connected" and will be permanently broken.

> I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> this option. That could allow /dev/console will still work the same way for
> user space logging, while disabling vgacon and fbcon.
> 
> And it could still be overridden by console=ttyS0, which I think is needed
> anyway if you have CONFIG_VT_CONSOLE enabled

That sounds safer. And even then, I still don't understand why the application
logging to /dev/console needs to block on it instead of just dropping whatever
doesn't fit there since that's the primary intent of an optional logging
console, i.e. emit events but without preventing regular operations. Maybe
*this* is the thing that would require a setting: wait or drop.

Just my two cents,
Willy

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Tuesday, August 27, 2024 9:46:49 AM EDT Willy Tarreau wrote:
> On Tue, Aug 27, 2024 at 08:53:49AM -0400, nerdopolis wrote:
> > > > If I get it correctly, you suggest to do not register serial port
> > > > when it is not physically connected. It makes some sense.
> > > > 
> > > Hmm, now that might work, and is a good idea...
> > Although now that I think about it, could this cause unintended behavior on
> > some hardware? Or folks that might plug in the serial cable after booting for
> > whatever reason?
> 
> The *vast* majority of serial ports spend their time non-connected, and
> are only used to connect to the equipment at runtime, to recover a lost
> access, or to connect locally to it during operations. What is proposed
> above scares me a little bit:
>   - PC-like serial ports (DB-9) support hardware flow control using the
>     RTS/CTS lines and are expected to be instantly usable when connecting
>     something to them. The presence of a cable is detectable, though many
>     will just have a local loop (CTS-RTS, DCD-DTR-DSR) and will in fact
>     only detect that the connector is plugged in. Some don't even connect
>     them, and turn off HW flow control.
> 
>   - many boards don't even have hardware flow control and only provide
>     the usual 3-4 pins (GND, TX, RX and optional VCC). These ones will
>     never be detected as "connected" and will be permanently broken.
> 
> > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > this option. That could allow /dev/console will still work the same way for
> > user space logging, while disabling vgacon and fbcon.
> > 
> > And it could still be overridden by console=ttyS0, which I think is needed
> > anyway if you have CONFIG_VT_CONSOLE enabled
> 
> That sounds safer. And even then, I still don't understand why the application
> logging to /dev/console needs to block on it instead of just dropping whatever
> doesn't fit there since that's the primary intent of an optional logging
> console, i.e. emit events but without preventing regular operations. Maybe
> *this* is the thing that would require a setting: wait or drop.
> 
Sorry about the late reply, the application that is logging and dropping is
kind of unintentional I think. From how I understand it, systemd wants to
verify that /dev/console is actually /dev/console, so it calls isatty() on it.

isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
and isatty() returns false, and systemd assumes that it is not a serial device,
and in turn it doesn't log because of that.

Thanks
> Just my two cents,
> Willy
> 

Re: VT-less kernels, and /dev/console on x86

[Willy Tarreau]

On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > > this option. That could allow /dev/console will still work the same way for
> > > user space logging, while disabling vgacon and fbcon.
> > > 
> > > And it could still be overridden by console=ttyS0, which I think is needed
> > > anyway if you have CONFIG_VT_CONSOLE enabled
> > 
> > That sounds safer. And even then, I still don't understand why the application
> > logging to /dev/console needs to block on it instead of just dropping whatever
> > doesn't fit there since that's the primary intent of an optional logging
> > console, i.e. emit events but without preventing regular operations. Maybe
> > *this* is the thing that would require a setting: wait or drop.
> > 
> Sorry about the late reply, the application that is logging and dropping is
> kind of unintentional I think. From how I understand it, systemd wants to
> verify that /dev/console is actually /dev/console, so it calls isatty() on it.

OK.

> isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
> device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
> and isatty() returns false, and systemd assumes that it is not a serial device,
> and in turn it doesn't log because of that.

I'm no tty expert at all, but on this machine I'm having this:

  # dmesg|grep console
  [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
  [    1.638242] printk: console [ttyS0] disabled
  [    2.848759] printk: console [ttyS0] enabled
  [   12.950334] systemd[1]: Starting Set the console keyboard layout...

  # cat /proc/consoles 
  ttyS0                -W- (EC p a)    4:64

  # strace -e trace=ioctl stty -a < /dev/console 
  ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
  ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
  ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
  speed 115200 baud; rows 24; columns 80; line = 0;
  intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
  werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
  -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
  -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
  opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
  -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
  +++ exited with 0 +++

So TCGETS succeeded above, and the console is unplugged. Even if I enable
HW flow control (crtscts) the result is the same BTW (I preferred to check).
Same if I enable carrier detection (-clocal).

So I'm unsure what would cause TCGETS to fail in your case.

Willy

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, September 12, 2024 1:25:22 PM EDT Willy Tarreau wrote:
> On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > > > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > > > this option. That could allow /dev/console will still work the same way for
> > > > user space logging, while disabling vgacon and fbcon.
> > > > 
> > > > And it could still be overridden by console=ttyS0, which I think is needed
> > > > anyway if you have CONFIG_VT_CONSOLE enabled
> > > 
> > > That sounds safer. And even then, I still don't understand why the application
> > > logging to /dev/console needs to block on it instead of just dropping whatever
> > > doesn't fit there since that's the primary intent of an optional logging
> > > console, i.e. emit events but without preventing regular operations. Maybe
> > > *this* is the thing that would require a setting: wait or drop.
> > > 
> > Sorry about the late reply, the application that is logging and dropping is
> > kind of unintentional I think. From how I understand it, systemd wants to
> > verify that /dev/console is actually /dev/console, so it calls isatty() on it.
> 
> OK.
> 
> > isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
> > device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
> > and isatty() returns false, and systemd assumes that it is not a serial device,
> > and in turn it doesn't log because of that.
> 
> I'm no tty expert at all, but on this machine I'm having this:
> 
>   # dmesg|grep console
>   [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
>   [    1.638242] printk: console [ttyS0] disabled
>   [    2.848759] printk: console [ttyS0] enabled
>   [   12.950334] systemd[1]: Starting Set the console keyboard layout...
> 
>   # cat /proc/consoles 
>   ttyS0                -W- (EC p a)    4:64
> 
>   # strace -e trace=ioctl stty -a < /dev/console 
>   ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>   ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
>   ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
>   speed 115200 baud; rows 24; columns 80; line = 0;
>   intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
>   werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
>   -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
>   -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
>   opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>   -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
>   +++ exited with 0 +++
> 
> So TCGETS succeeded above, and the console is unplugged. Even if I enable
> HW flow control (crtscts) the result is the same BTW (I preferred to check).
> Same if I enable carrier detection (-clocal).
> 
I think you bypassed the issue by specifying a baudrate (which must be forcing
it on?) instead of letting it select an automatic one. try with just
console=ttyS0 ? 
> So I'm unsure what would cause TCGETS to fail in your case.
> 
> Willy
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, September 12, 2024 2:46:04 PM EDT nerdopolis wrote:
> On Thursday, September 12, 2024 1:25:22 PM EDT Willy Tarreau wrote:
> > On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > > > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > > > > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > > > > this option. That could allow /dev/console will still work the same way for
> > > > > user space logging, while disabling vgacon and fbcon.
> > > > > 
> > > > > And it could still be overridden by console=ttyS0, which I think is needed
> > > > > anyway if you have CONFIG_VT_CONSOLE enabled
> > > > 
> > > > That sounds safer. And even then, I still don't understand why the application
> > > > logging to /dev/console needs to block on it instead of just dropping whatever
> > > > doesn't fit there since that's the primary intent of an optional logging
> > > > console, i.e. emit events but without preventing regular operations. Maybe
> > > > *this* is the thing that would require a setting: wait or drop.
> > > > 
> > > Sorry about the late reply, the application that is logging and dropping is
> > > kind of unintentional I think. From how I understand it, systemd wants to
> > > verify that /dev/console is actually /dev/console, so it calls isatty() on it.
> > 
> > OK.
> > 
> > > isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
> > > device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
> > > and isatty() returns false, and systemd assumes that it is not a serial device,
> > > and in turn it doesn't log because of that.
> > 
> > I'm no tty expert at all, but on this machine I'm having this:
> > 
> >   # dmesg|grep console
> >   [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
> >   [    1.638242] printk: console [ttyS0] disabled
> >   [    2.848759] printk: console [ttyS0] enabled
> >   [   12.950334] systemd[1]: Starting Set the console keyboard layout...
> > 
> >   # cat /proc/consoles 
> >   ttyS0                -W- (EC p a)    4:64
> > 
> >   # strace -e trace=ioctl stty -a < /dev/console 
> >   ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> >   ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
> >   ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
> >   speed 115200 baud; rows 24; columns 80; line = 0;
> >   intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> >   werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
> >   -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
> >   -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
> >   opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> >   -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
> >   +++ exited with 0 +++
> > 
> > So TCGETS succeeded above, and the console is unplugged. Even if I enable
> > HW flow control (crtscts) the result is the same BTW (I preferred to check).
> > Same if I enable carrier detection (-clocal).
> > 
> I think you bypassed the issue by specifying a baudrate (which must be forcing
> it on?) instead of letting it select an automatic one. try with just
> console=ttyS0 ? 
> > So I'm unsure what would cause TCGETS to fail in your case.
> > 
Looks line I am wrong about the baud rate turning it on, I did more testing.
That is odd, I tested on my laptop and on qemu with "-serial none" and booting 
with console=ttyS0 and stty results in an input output error.
> > Willy
> > 
> 
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, September 12, 2024 2:46:04 PM EDT nerdopolis wrote:
> On Thursday, September 12, 2024 1:25:22 PM EDT Willy Tarreau wrote:
> > On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > > > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > > > > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > > > > this option. That could allow /dev/console will still work the same way for
> > > > > user space logging, while disabling vgacon and fbcon.
> > > > > 
> > > > > And it could still be overridden by console=ttyS0, which I think is needed
> > > > > anyway if you have CONFIG_VT_CONSOLE enabled
> > > > 
> > > > That sounds safer. And even then, I still don't understand why the application
> > > > logging to /dev/console needs to block on it instead of just dropping whatever
> > > > doesn't fit there since that's the primary intent of an optional logging
> > > > console, i.e. emit events but without preventing regular operations. Maybe
> > > > *this* is the thing that would require a setting: wait or drop.
> > > > 
> > > Sorry about the late reply, the application that is logging and dropping is
> > > kind of unintentional I think. From how I understand it, systemd wants to
> > > verify that /dev/console is actually /dev/console, so it calls isatty() on it.
> > 
> > OK.
> > 
> > > isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
> > > device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
> > > and isatty() returns false, and systemd assumes that it is not a serial device,
> > > and in turn it doesn't log because of that.
> > 
> > I'm no tty expert at all, but on this machine I'm having this:
> > 
> >   # dmesg|grep console
> >   [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
> >   [    1.638242] printk: console [ttyS0] disabled
> >   [    2.848759] printk: console [ttyS0] enabled
> >   [   12.950334] systemd[1]: Starting Set the console keyboard layout...
> > 
> >   # cat /proc/consoles 
> >   ttyS0                -W- (EC p a)    4:64
> > 
> >   # strace -e trace=ioctl stty -a < /dev/console 
> >   ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
> >   ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
> >   ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
> >   speed 115200 baud; rows 24; columns 80; line = 0;
> >   intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> >   werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
> >   -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
> >   -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
> >   opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> >   -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
> >   +++ exited with 0 +++
> > 
> > So TCGETS succeeded above, and the console is unplugged. Even if I enable
> > HW flow control (crtscts) the result is the same BTW (I preferred to check).
> > Same if I enable carrier detection (-clocal).
> > 
> I think you bypassed the issue by specifying a baudrate (which must be forcing
> it on?) instead of letting it select an automatic one. try with just
> console=ttyS0 ? 
> > So I'm unsure what would cause TCGETS to fail in your case.
> > 
> > Willy
> > 
Were you able to replicate it on a qemu machine with '-serial none' by chance?
> 
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Thursday, September 12, 2024 1:25:22 PM EDT Willy Tarreau wrote:
> On Thu, Sep 12, 2024 at 12:48:01PM -0400, nerdopolis wrote:
> > > > I still kind of lean to CONFIG_NULL_TTY_CONSOLE, that way if enabled, and in
> > > > theory, only distributions that had CONFIG_VT_CONSOLE turned on would turn on
> > > > this option. That could allow /dev/console will still work the same way for
> > > > user space logging, while disabling vgacon and fbcon.
> > > > 
> > > > And it could still be overridden by console=ttyS0, which I think is needed
> > > > anyway if you have CONFIG_VT_CONSOLE enabled
> > > 
> > > That sounds safer. And even then, I still don't understand why the application
> > > logging to /dev/console needs to block on it instead of just dropping whatever
> > > doesn't fit there since that's the primary intent of an optional logging
> > > console, i.e. emit events but without preventing regular operations. Maybe
> > > *this* is the thing that would require a setting: wait or drop.
> > > 
> > Sorry about the late reply, the application that is logging and dropping is
> > kind of unintentional I think. From how I understand it, systemd wants to
> > verify that /dev/console is actually /dev/console, so it calls isatty() on it.
> 
> OK.
> 
> > isatty() in turn calls the TCGETS ioctl on /dev/console, which when the console
> > device is actually /dev/ttyS0, and /dev/ttyS0 is unplugged, it the ioctl fails,
> > and isatty() returns false, and systemd assumes that it is not a serial device,
> > and in turn it doesn't log because of that.
> 
> I'm no tty expert at all, but on this machine I'm having this:
> 
>   # dmesg|grep console
>   [    0.000000] Kernel command line: boot_image=l0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait
>   [    1.638242] printk: console [ttyS0] disabled
>   [    2.848759] printk: console [ttyS0] enabled
>   [   12.950334] systemd[1]: Starting Set the console keyboard layout...
> 
>   # cat /proc/consoles 
>   ttyS0                -W- (EC p a)    4:64
> 
>   # strace -e trace=ioctl stty -a < /dev/console 
>   ioctl(0, TCGETS, {B115200 opost -isig -icanon -echo ...}) = 0
>   ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=152, ws_xpixel=1534, ws_ypixel=604}) = 0
>   ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
>   speed 115200 baud; rows 24; columns 80; line = 0;
>   intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
>   werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
>   -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
>   -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
>   opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>   -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
>   +++ exited with 0 +++
> 
> So TCGETS succeeded above, and the console is unplugged. Even if I enable
> HW flow control (crtscts) the result is the same BTW (I preferred to check).
> Same if I enable carrier detection (-clocal).
> 
> So I'm unsure what would cause TCGETS to fail in your case.
> 
I am still kind of curious why TCGETS is succeeding in your case.
What is your /sys/devices/virtual/tty/console/active
and have you tried in a QEMU VM with -serial none ?
> Willy
> 

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > 
> > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > Hi
> > > > > > > 
> > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > refuses to write log messages to it.
> > > > > > > 
> > > > > > > There doesn't seem to be a mailing list for printk, so I had to use
> > > > > > > get_maintainer.pl. Hopefully this is correct
> > > > > > > 
> > > > > > > 
> > > > > > > After some grepping and guessing and testing, and playing around Something like
> > > > > > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > > > > > index a45d423ad10f..f94a4632aab0 100644
> > > > > > > --- a/drivers/tty/Kconfig
> > > > > > > +++ b/drivers/tty/Kconfig
> > > > > > > @@ -384,9 +384,12 @@ config NULL_TTY
> > > > > > >  
> > > > > > >           In order to use this driver, you should redirect the console to this
> > > > > > >           TTY, or boot the kernel with console=ttynull.
> > > > > > > -
> > > > > > >           If unsure, say N.
> > > > > > >  
> > > > > > > +config NULL_TTY_CONSOLE
> > > > > > > +        bool "Supports /dev/ttynull as a console automatically"
> > > > > > > +        depends on NULL_TTY && !VT_CONSOLE
> > > > > > > +
> > > > > > >  config VCC
> > > > > > >         tristate "Sun Virtual Console Concentrator"
> > > > > > >         depends on SUN_LDOMS
> > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > > > index dddb15f48d59..c1554a789de8 100644
> > > > > > > --- a/kernel/printk/printk.c
> > > > > > > +++ b/kernel/printk/printk.c
> > > > > > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > > > > > >         initcall_t call;
> > > > > > >         initcall_entry_t *ce;
> > > > > > >  
> > > > > > > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > > > > > > +       if (!strstr(boot_command_line, "console="))
> > > > > > > +               add_preferred_console("ttynull", 0, NULL);
> > > > > > > +#endif
> > > > > > > +
> > > > > > >         /* Setup the default TTY line discipline. */
> > > > > > >         n_tty_init();
> > > > > > >  
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > seems to work, it conflicts with CONFIG_VT_CONSOLE since it is effectively
> > > > > > > redundant, it is optional, so that it doesn't cause any changes to
> > > > > > > configurations, that historically had CONFIG_VT_CONSOLE turned off in the past,
> > > > > > > and for bootloader configs, it won't change any behavior if the kernel command
> > > > > > > line has a console device specified  
> > > > > > 
> > > > > > What is wrong with just setting the kernel command line for this
> > > > > > instead?
> > > > > >   
> > > > > When they eventually start shipping kernels without VTs, they will then have to
> > > > > include a script in their upgrade process that runs
> > > > > 
> > > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"nomodeset /g" /etc/default/grub  
> > > > Ugh, I meant
> > > > sed -i "s/GRUB_CMDLINE_LINUX_DEFAULT=\"/GRUB_CMDLINE_LINUX_DEFAULT=\"console=ttynull /g" /etc/default/grub
> > > > sorry
> > > 
> > > If you can modify the kernel .config for this, can you just update:
> > > 
> > >   CONFIG_CMDLINE_BOOL=y
> > >   CONFIG_CMDLINE="console=ttynull"
> > > 
> > > ?
> > > 
> > That could work, I think. I'll have to see how that works when a different
> > console= is specified on the command line from the bootloader though, I am
> > thinking that if console=ttyS0 is then manually specified by a user, there will
> > be two devices in /proc/consoles (ttyS0 on top of ttynull), but I admit I don't
> > know if there are actual ramifications of that, or not...
> 
> I guess that it would register both consoles in this case.
> 
> > I am not sure if real distributions would want this to be the answer I guess I
> > will have to see if any others are using CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE,
> > although this gives me an idea..
> > 
> > Would something like this below be more acceptable? I didn't test it yet, but
> > just the theory. I am thinking that this could have more use to allow a
> > preferred to be set...
> > 
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index dddb15f48d59..c1554a789de8 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> >  	initcall_t call;
> >  	initcall_entry_t *ce;
> >  
> > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > +       if (!strstr(boot_command_line, "console="))
> > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > +#endif
> > +
> >  	/* Setup the default TTY line discipline. */
> >  	n_tty_init();
> 
> This is better. But it does not handle some situations. For example,
> default console might also by defined by:
> 
>    + scpr, see acpi_parse_spcr()
>    + device tree, see of_console_check()
>    + netconsole=, it is hidden in init_netconsole()
> 
> I tried to handle this another way. The "ttynull" console was
> added when /dev/console could not be opened in console_on_rootfs(),
> see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> as a fallback when there is no console").
> 
> But it did not work well and we had to revert the change, see
> the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> ttynull as a fallback when there is no console").
> 
Out of curiosity, would the upcoming nbcon work fix the race conditions or
problems that were seen in 757055ae8dedf5333af17b ?
> Another idea:
> 
> 1. We could use the same trick as netconsole. I mean to use:
> 
> 	ttynull_console.flags |= CON_ENABLED;
> 
>    to force register_console() to register the console even
>    when it is not defined in the list of preferred consoles.
> 
>    It is a kind of hack. But it looks cleaner that adding
>    ttynull console into the list of preferred consoles.
> 
> 
> 2. We need to decide whether the fallback to ttynull console
>    is needed as late as possible. It should be done after
>    all other drivers call register_console().
> 
>    I would do it in late_initcall_sync().
> 
> 
> 3. We need to detect when the fallback is needed. The check
>    of /dev/console does not work, see
>    the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
>    ttynull as a fallback when there is no console").
> 
>    A solution might be to check if @console_list is empty.
> 
> 
> Something like (not even compile tested):
> 
> diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> index 6b2f7208b564..7cd7ba2ec33c 100644
> --- a/drivers/tty/ttynull.c
> +++ b/drivers/tty/ttynull.c
> @@ -59,6 +59,16 @@ static struct console ttynull_console = {
>  	.device = ttynull_device,
>  };
>  
> +void __init register_ttynull_console_force(void)
> +{
> +	if (!ttynull_driver)
> +		return;
> +
> +	/* Force registration by setting the CON_ENABLED flag. */
> +	ttynull_console.flags |= CON_ENABLED;
> +	register_console(&ttynull_console);
> +}
> +
>  static int __init ttynull_init(void)
>  {
>  	struct tty_driver *driver;
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 054c0e7784fd..004612e6fc7f 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3857,6 +3857,25 @@ static int __init printk_late_init(void)
>  }
>  late_initcall(printk_late_init);
>  
> +static int __init console_fallback(void)
> +{
> +	bool need_fallback = false;
> +
> +	console_list_lock();
> +	/*
> +	 * Make sure that there is a console which can be associated
> +	 * with /dev/console
> +	 */
> +	if (hlist_empty(&console_list))
> +		need_fallback = true;
> +
> +	console_list_unlock();
> +
> +	if (need_fallback)
> +		register_ttynull_console_force();
> +}
> +late_initcall_sync(console_fallback);
> +
>  #if defined CONFIG_PRINTK
>  /* If @con is specified, only wait for that console. Otherwise wait for all. */
>  static bool __pr_flush(struct console *con, int timeout_ms, bool reset_on_progress)
> 
> 
> 
> The above code would need some love to compile without
> CONFIG_NULL_TTY.
> 
> Also it still might break some system/configuration where the default
> console driver calls register_console() later.
> 
> We might need to update the check in register_console() and
> call try_enable_default_console() even when ttynull console
> is already registered as a fallback. We might even want
> to unregister the ttynull console in this case.
> 
> Best Regards,
> Petr
> 

Re: VT-less kernels, and /dev/console on x86

[Petr Mladek]

On Thu 2024-09-12 08:29:26, nerdopolis wrote:
> On Tuesday, August 20, 2024 9:29:36 AM EDT Petr Mladek wrote:
> > On Mon 2024-08-19 11:50:39, nerdopolis wrote:
> > > On Monday, August 19, 2024 11:09:35 AM EDT Steven Rostedt wrote:
> > > > On Sun, 18 Aug 2024 10:30:22 -0400
> > > > nerdopolis <bluescreen_avenger@verizon.net> wrote:
> > > > > On Sunday, August 18, 2024 8:33:25 AM EDT nerdopolis wrote:
> > > > > > On Sunday, August 18, 2024 1:12:14 AM EDT Greg KH wrote:  
> > > > > > > On Sat, Aug 17, 2024 at 08:09:20PM -0400, nerdopolis wrote:  
> > > > > > > > I originally brought this up on linux-serial, but I think it makes more sense
> > > > > > > > that it's part of how printk console device selection works. Without VTs, while
> > > > > > > > most software is able to handle the situation, some userspace programs expect
> > > > > > > > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > > > > > > > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > > > > > > > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > > > > > > > refuses to write log messages to it.
> > > > > > > > 
> > > Would something like this below be more acceptable? I didn't test it yet, but
> > > just the theory. I am thinking that this could have more use to allow a
> > > preferred to be set...
> > > 
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index dddb15f48d59..c1554a789de8 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > >  	initcall_t call;
> > >  	initcall_entry_t *ce;
> > >  
> > > +#ifdef CONFIG_DEFAULT_CONSOLE_HINT_BOOL
> > > +       if (!strstr(boot_command_line, "console="))
> > > +               add_preferred_console(CONFIG_DEFAULT_CONSOLE_HINT, 0, NULL);
> > > +#endif
> > > +
> > >  	/* Setup the default TTY line discipline. */
> > >  	n_tty_init();
> > 
> > This is better. But it does not handle some situations. For example,
> > default console might also by defined by:
> > 
> >    + scpr, see acpi_parse_spcr()
> >    + device tree, see of_console_check()
> >    + netconsole=, it is hidden in init_netconsole()
> > 
> > I tried to handle this another way. The "ttynull" console was
> > added when /dev/console could not be opened in console_on_rootfs(),
> > see the commit 757055ae8dedf5333af17b ("init/console: Use ttynull
> > as a fallback when there is no console").
> > 
> > But it did not work well and we had to revert the change, see
> > the commit a91bd6223ecd46addc71ee6f ("Revert "init/console: Use
> > ttynull as a fallback when there is no console").
> > 
> Out of curiosity, would the upcoming nbcon work fix the race conditions or
> problems that were seen in 757055ae8dedf5333af17b ?

Not really. The nbcon work affects the context and locking used for
flushing of the consoles. It does _not_ affect the registration. And
it does _not_ affect how the consoles are associated with /dev/console.

Best Regards,
Petr

Re: VT-less kernels, and /dev/console on x86

[Bernd Petrovitsch]

Hi all!

On 18.08.24 02:09, nerdopolis wrote:
[...]
> I originally brought this up on linux-serial, but I think it makes more sense
> that it's part of how printk console device selection works. Without VTs, while
> most software is able to handle the situation, some userspace programs expect
> /dev/console to still be responsive. Namely systemd. It calls isatty() against
> /dev/console, and since /dev/console on VT-less systems currently defaults to
> /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> refuses to write log messages to it.

What's wrong with fixing systemd?

Kind regards,
	Bernd
-- 
-- 
mobile: +43 664 4416156               http://www.sysprog.at/
Embedded Linux Software Development, Consulting and Services

Re: VT-less kernels, and /dev/console on x86

[nerdopolis]

On Wednesday, October 9, 2024 5:24:49 AM EDT Bernd Petrovitsch wrote:
> Hi all!
> 
> On 18.08.24 02:09, nerdopolis wrote:
> [...]
> > I originally brought this up on linux-serial, but I think it makes more sense
> > that it's part of how printk console device selection works. Without VTs, while
> > most software is able to handle the situation, some userspace programs expect
> > /dev/console to still be responsive. Namely systemd. It calls isatty() against
> > /dev/console, and since /dev/console on VT-less systems currently defaults to
> > /dev/ttyS0, and when /dev/ttyS0 is disconnected, the ioctl's fail, and it
> > refuses to write log messages to it.
> 
> What's wrong with fixing systemd?
The change was rejected, as they want the isatty() call on /dev/console
despite it returning false due to the i/o error

https://github.com/systemd/systemd/pull/33690
> 
> Kind regards,
> 	Bernd
>