/dev/ttynull and VT-less kernels on Desktop
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): 2708910.X9hSmTKtgW.ref@nerdopolis2
Hi
I have been doing some testing on VT-less desktops. I brought up an issue with how systemd was not logging to /dev/console because isatty() was failing (in a thread last month which I kind of bungled by accidentally sending the first message with rich text enabled by accident) I solved that issue though. As disabling the VT console causes the default console to /dev/ttyS0 and the isatty() calls on it were returning false.
I have found out that this issue actually already has an existing solution in the ttynull driver. After enabling it, and then adding console=ttynull to the kernel command line, this allows isatty() to succeed on VT-less systems, and now systemd is able to correctly log its status messages to the kernel console on VT-less systems, without needing anything connected to /dev/ttyS0
However I have two questions:
1. Is there a build option to make it prioritize /dev/ttynull over /dev/ttyS0 ?
It would probably be neeed so that distributions don't have to worry about the logistics of adding that to everyone's GRUB_CMDLINE_LINUX_DEFAULT come the eventual day the decide to go VT-less during its upgrade process.
2. Is there a good way for the userspace to know that /dev/ttynull is primary?
"ttynull" doesn't seem to appear in /sys/devices/virtual/tty/console/active when it is active. Which seems like it could make sense, (as in a check if it is empty) however if I boot with "console=ttyS0 console=ttynull", "ttyS0" appears in the file, but if I boot with say "console=tty0 console=ttyS0", they both appear in the file. It would be nice if in the first case it would report "ttyS0 ttynull".
With Plymouth, when the primary console is /dev/ttyS0 instead of /dev/tty0 it defaults to serial logging instead of showing a graphical splash, so now if you want a graphical splash on a VT-less system, you have to also specify "plymouth.graphical" on the kernel command line. If it could see "ttynull" in the end of the file, distributions that go VT-less can also just enable "ttynull" as the default console, and Plymouth could use that to differentiate between VT-less desktop systems, or systems that actually want serial logging, so they don't have to change GRUB_CMDLINE_LINUX_DEFAULT.
Thanks
Quoted 17 lines · EDT nerdopolis
Hi
I have been doing some testing on VT-less desktops. I brought up an issue with how systemd was not logging to
/dev/consolebecauseisatty()was failing (in a thread last month which I kind of bungled by accidentally sending the first message with rich text enabled by accident) I solved that issue though. As disabling the VT console causes the default console to/dev/ttyS0and theisatty()calls on it were returning false.I have found out that this issue actually already has an existing solution in the ttynull driver. After enabling it, and then adding console=ttynull to the kernel command line, this allows
isatty()to succeed on VT-less systems, and now systemd is able to correctly log its status messages to the kernel console on VT-less systems, without needing anything connected to/dev/ttyS0However I have two questions:
Quoted 8 lines
1. Is there a build option to make it prioritize
/dev/ttynullover/dev/ttyS0?It would probably be neeed so that distributions don't have to worry about the logistics of adding that to everyone's
GRUB_CMDLINE_LINUX_DEFAULTcome the eventual day the decide to go VT-less during its upgrade process.2. Is there a good way for the userspace to know that
/dev/ttynullis primary?
Hi
So I think I figured this part out, while ttynull doesn't make its way into the /sys/devices/virtual/tty/console/active file, it is reported in /proc/consoles so I will read from there, seems like the primary console is always the first line, so this part is solved
Thanks
Quoted 22 lines
"ttynull" doesn't seem to appear in
/sys/devices/virtual/tty/console/activewhen it is active. Which seems like it could make sense, (as in a check if it is empty) however if I boot with "console=ttyS0 console=ttynull", "ttyS0" appears in the file, but if I boot with say "console=tty0 console=ttyS0", they both appear in the file. It would be nice if in the first case it would report "ttyS0 ttynull".With Plymouth, when the primary console is
/dev/ttyS0instead of/dev/tty0it defaults to serial logging instead of showing a graphical splash, so now if you want a graphical splash on a VT-less system, you have to also specify "plymouth.graphical" on the kernel command line. If it could see "ttynull" in the end of the file, distributions that go VT-less can also just enable "ttynull" as the default console, and Plymouth could use that to differentiate between VT-less desktop systems, or systems that actually want serial logging, so they don't have to changeGRUB_CMDLINE_LINUX_DEFAULT.Thanks
Quoted 16 lines · EDT nerdopolis
Quoted 15 lines · EDT nerdopolis
Hi
I have been doing some testing on VT-less desktops. I brought up an issue with how systemd was not logging to
/dev/consolebecauseisatty()was failing (in a thread last month which I kind of bungled by accidentally sending the first message with rich text enabled by accident) I solved that issue though. As disabling the VT console causes the default console to/dev/ttyS0and theisatty()calls on it were returning false.I have found out that this issue actually already has an existing solution in the ttynull driver. After enabling it, and then adding console=ttynull to the kernel command line, this allows
isatty()to succeed on VT-less systems, and now systemd is able to correctly log its status messages to the kernel console on VT-less systems, without needing anything connected to/dev/ttyS0
Quoted 4 lines
Quoted 4 lines
However I have two questions:
1. Is there a build option to make it prioritize
/dev/ttynullover/dev/ttyS0?
Hi
So I was able to come up with a hackish tweak, making a CONFIG_NULL_TTY_CONSOLE it would depend on CONFIG_NULL_TTY being enabled, and CONFIG_VT_CONSOLE being NOT enabled.
and then doing a
-------------------------------------------------------------------------------
kernel/printk/printk.c +4 -0
@@ -3728,6 +3728,10 @@ void __init console_init(void)trace_initcall_finish (call, ret); ce++; } +#ifdef CONFIG_NULL_TTY_CONSOLE +if (preferred_console <0 ) +__add_preferred_console ("ttynull" ,0 ,NULL ,NULL , false); +#endif }/*
-------------------------------------------------------------------------------
It's probably not correct, but it works for me locally, after some grepping and guessing...
Thanks
Quoted 41 lines
Quoted 6 lines
It would probably be neeed so that distributions don't have to worry about the logistics of adding that to everyone's
GRUB_CMDLINE_LINUX_DEFAULTcome the eventual day the decide to go VT-less during its upgrade process.2. Is there a good way for the userspace to know that
/dev/ttynullis primary?Hi
So I think I figured this part out, while ttynull doesn't make its way into the
/sys/devices/virtual/tty/console/activefile, it is reported in/proc/consolesso I will read from there, seems like the primary console is always the first line, so this part is solvedThanks
Quoted 22 lines
"ttynull" doesn't seem to appear in
/sys/devices/virtual/tty/console/activewhen it is active. Which seems like it could make sense, (as in a check if it is empty) however if I boot with "console=ttyS0 console=ttynull", "ttyS0" appears in the file, but if I boot with say "console=tty0 console=ttyS0", they both appear in the file. It would be nice if in the first case it would report "ttyS0 ttynull".With Plymouth, when the primary console is
/dev/ttyS0instead of/dev/tty0it defaults to serial logging instead of showing a graphical splash, so now if you want a graphical splash on a VT-less system, you have to also specify "plymouth.graphical" on the kernel command line. If it could see "ttynull" in the end of the file, distributions that go VT-less can also just enable "ttynull" as the default console, and Plymouth could use that to differentiate between VT-less desktop systems, or systems that actually want serial logging, so they don't have to changeGRUB_CMDLINE_LINUX_DEFAULT.Thanks