* /dev/ttynull and VT-less kernels on Desktop [not found] <2708910.X9hSmTKtgW.ref@nerdopolis2> @ 2024-08-04 21:45 ` nerdopolis 2024-08-06 1:16 ` nerdopolis 0 siblings, 1 reply; 3+ messages in thread From: nerdopolis @ 2024-08-04 21:45 UTC (permalink / raw) To: linux-serial, gregkh, jirislaby 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: /dev/ttynull and VT-less kernels on Desktop 2024-08-04 21:45 ` /dev/ttynull and VT-less kernels on Desktop nerdopolis @ 2024-08-06 1:16 ` nerdopolis 2024-08-10 15:10 ` nerdopolis 0 siblings, 1 reply; 3+ messages in thread From: nerdopolis @ 2024-08-06 1:16 UTC (permalink / raw) To: linux-serial, gregkh, jirislaby, bluescreen_avenger On Sunday, August 4, 2024 5:45:07 PM EDT nerdopolis wrote: > 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? > 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 > "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 > > > > > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: /dev/ttynull and VT-less kernels on Desktop 2024-08-06 1:16 ` nerdopolis @ 2024-08-10 15:10 ` nerdopolis 0 siblings, 0 replies; 3+ messages in thread From: nerdopolis @ 2024-08-10 15:10 UTC (permalink / raw) To: linux-serial, gregkh, jirislaby On Monday, August 5, 2024 9:16:21 PM EDT nerdopolis wrote: > On Sunday, August 4, 2024 5:45:07 PM EDT nerdopolis wrote: > > 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 ? > > 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 ------------------------------------------------------------------------------- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index dddb15f48d59..6950118c6fb3 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -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 > > 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? > > > 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 > > "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 > > > > > > > > > > > > > > > ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-08-10 15:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2708910.X9hSmTKtgW.ref@nerdopolis2>
2024-08-04 21:45 ` /dev/ttynull and VT-less kernels on Desktop nerdopolis
2024-08-06 1:16 ` nerdopolis
2024-08-10 15:10 ` nerdopolis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox