* /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;
as well as URLs for NNTP newsgroup(s).