[PATCH] tty: Add NULL TTY driver

[PATCH] tty: Add NULL TTY driver

[Vincent Whitchurch]

If no console driver is enabled (or if a non-present driver is selected
with something like console=null in an attempt to disable the console),
opening /dev/console errors out, and init scripts and other userspace
code that relies on the existence of a console will fail.  Symlinking
/dev/null to /dev/console does not solve the problem since /dev/null
does not behave like a real TTY.

To just provide a dummy console to userspace when no console driver is
available or desired, add a ttynull driver which simply discards all
writes.  It can be chosen on the command line in the standard way, i.e.
with console=ttynull.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/tty/Kconfig   |  14 ++++++
 drivers/tty/Makefile  |   1 +
 drivers/tty/ttynull.c | 109 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 124 insertions(+)
 create mode 100644 drivers/tty/ttynull.c

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index e0a04bfc873e..d862f442f389 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -376,6 +376,20 @@ config PPC_EARLY_DEBUG_EHV_BC_HANDLE
 	  there simply will be no early console output.  This is true also
 	  if you don't boot under a hypervisor at all.
 
+config NULL_TTY
+	tristate "NULL TTY driver"
+	help
+	  Say Y here if you want a NULL TTY which simply discards messages.
+
+	  This is useful to allow userspace applications which expect a console
+	  device to work without modifications even when no console is
+	  available or desired.
+
+	  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 GOLDFISH_TTY
 	tristate "Goldfish TTY Driver"
 	depends on GOLDFISH
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index c72cafdf32b4..020b1cd9294f 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ISI)		+= isicom.o
 obj-$(CONFIG_MOXA_INTELLIO)	+= moxa.o
 obj-$(CONFIG_MOXA_SMARTIO)	+= mxser.o
 obj-$(CONFIG_NOZOMI)		+= nozomi.o
+obj-$(CONFIG_NULL_TTY)	        += ttynull.o
 obj-$(CONFIG_ROCKETPORT)	+= rocket.o
 obj-$(CONFIG_SYNCLINK_GT)	+= synclink_gt.o
 obj-$(CONFIG_SYNCLINKMP)	+= synclinkmp.o
diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
new file mode 100644
index 000000000000..17f05b7eb6d3
--- /dev/null
+++ b/drivers/tty/ttynull.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Axis Communications AB
+ *
+ * Based on ttyprintk.c:
+ *  Copyright (C) 2010 Samo Pogacnik
+ */
+
+#include <linux/console.h>
+#include <linux/module.h>
+#include <linux/tty.h>
+
+static const struct tty_port_operations ttynull_port_ops;
+static struct tty_driver *ttynull_driver;
+static struct tty_port ttynull_port;
+
+static int ttynull_open(struct tty_struct *tty, struct file *filp)
+{
+	return tty_port_open(&ttynull_port, tty, filp);
+}
+
+static void ttynull_close(struct tty_struct *tty, struct file *filp)
+{
+	tty_port_close(&ttynull_port, tty, filp);
+}
+
+static void ttynull_hangup(struct tty_struct *tty)
+{
+	tty_port_hangup(&ttynull_port);
+}
+
+static int ttynull_write(struct tty_struct *tty, const unsigned char *buf,
+			 int count)
+{
+	return count;
+}
+
+static int ttynull_write_room(struct tty_struct *tty)
+{
+	return 65536;
+}
+
+static const struct tty_operations ttynull_ops = {
+	.open = ttynull_open,
+	.close = ttynull_close,
+	.hangup = ttynull_hangup,
+	.write = ttynull_write,
+	.write_room = ttynull_write_room,
+};
+
+static struct tty_driver *ttynull_device(struct console *c, int *index)
+{
+	*index = 0;
+	return ttynull_driver;
+}
+
+static struct console ttynull_console = {
+	.name = "ttynull",
+	.device = ttynull_device,
+};
+
+static int __init ttynull_init(void)
+{
+	struct tty_driver *driver;
+	int ret;
+
+	driver = tty_alloc_driver(1,
+		TTY_DRIVER_RESET_TERMIOS |
+		TTY_DRIVER_REAL_RAW |
+		TTY_DRIVER_UNNUMBERED_NODE);
+	if (IS_ERR(driver))
+		return PTR_ERR(driver);
+
+	tty_port_init(&ttynull_port);
+	ttynull_port.ops = &ttynull_port_ops;
+
+	driver->driver_name = "ttynull";
+	driver->name = "ttynull";
+	driver->type = TTY_DRIVER_TYPE_CONSOLE;
+	driver->init_termios = tty_std_termios;
+	driver->init_termios.c_oflag = OPOST | OCRNL | ONOCR | ONLRET;
+	tty_set_operations(driver, &ttynull_ops);
+	tty_port_link_device(&ttynull_port, driver, 0);
+
+	ret = tty_register_driver(driver);
+	if (ret < 0) {
+		put_tty_driver(driver);
+		tty_port_destroy(&ttynull_port);
+		return ret;
+	}
+
+	ttynull_driver = driver;
+	register_console(&ttynull_console);
+
+	return 0;
+}
+
+static void __exit ttynull_exit(void)
+{
+	unregister_console(&ttynull_console);
+	tty_unregister_driver(ttynull_driver);
+	put_tty_driver(ttynull_driver);
+	tty_port_destroy(&ttynull_port);
+}
+
+module_init(ttynull_init);
+module_exit(ttynull_exit);
+
+MODULE_LICENSE("GPL v2");
-- 
2.20.0

Re: [PATCH] tty: Add NULL TTY driver

[Greg KH]

On Wed, Apr 03, 2019 at 01:33:27PM +0200, Vincent Whitchurch wrote:
> If no console driver is enabled (or if a non-present driver is selected
> with something like console=null in an attempt to disable the console),
> opening /dev/console errors out, and init scripts and other userspace
> code that relies on the existence of a console will fail.  Symlinking
> /dev/null to /dev/console does not solve the problem since /dev/null
> does not behave like a real TTY.
> 
> To just provide a dummy console to userspace when no console driver is
> available or desired, add a ttynull driver which simply discards all
> writes.  It can be chosen on the command line in the standard way, i.e.
> with console=ttynull.

If they have a broken system that sets "console=null", why would they
know to fix it to be "console=ttynull"?

I'm all for adding new functionality, but to provide kernel code because
userspace just isn't configured properly, that feels really wrong to me.

Now if this were to be the "default" if nothing is set up at all, that
might make a bit more sense, but as-is, this doesn't seem very useful.

thanks,

greg k-h

Re: [PATCH] tty: Add NULL TTY driver

[Vincent Whitchurch]

On Wed, Apr 03, 2019 at 03:12:13PM +0200, Greg KH wrote:
> On Wed, Apr 03, 2019 at 01:33:27PM +0200, Vincent Whitchurch wrote:
> > If no console driver is enabled (or if a non-present driver is selected
> > with something like console=null in an attempt to disable the console),
> > opening /dev/console errors out, and init scripts and other userspace
> > code that relies on the existence of a console will fail.  Symlinking
> > /dev/null to /dev/console does not solve the problem since /dev/null
> > does not behave like a real TTY.
> > 
> > To just provide a dummy console to userspace when no console driver is
> > available or desired, add a ttynull driver which simply discards all
> > writes.  It can be chosen on the command line in the standard way, i.e.
> > with console=ttynull.
> 
> If they have a broken system that sets "console=null", why would they
> know to fix it to be "console=ttynull"?
> 
> I'm all for adding new functionality, but to provide kernel code because
> userspace just isn't configured properly, that feels really wrong to me.

Especially on embedded systems, it would be convenient to have a simple
way to disable the console (both for kernel and userspace) on a system
which normally uses it, to free up the UART for other things.

In my case some early init script in userspace was actually tring to
handle the lack of a console in this way:

 [ ! -w /dev/console ] || exec 2>/dev/console

but the problem is that /dev/console always exists but fails on write,
so the obvious way of handling missing devices doesn't work.  AFAICS the
only way to get rid of /dev/console would be to disable the TTY layer
entirely in the kernel or have early userspace delete the file from
devtmpfs.

> Now if this were to be the "default" if nothing is set up at all, that
> might make a bit more sense, but as-is, this doesn't seem very useful.

Making it the default now would break users, wouldn't it?  Since IIRC if
no console is selected, the first registered console will automatically
be used by default.

Re: [PATCH] tty: Add NULL TTY driver

[Enrico Weigelt, metux IT consult]

On 03.04.19 16:11, Vincent Whitchurch wrote:

> Especially on embedded systems, it would be convenient to have a simple
> way to disable the console (both for kernel and userspace) on a system
> which normally uses it, to free up the UART for other things.

Just symlinking to /dev/null does not work ?

OTOH, if you're introducing a dummy console, wouldn't a ringbuffer that,
can be read out later, a better option ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [PATCH] tty: Add NULL TTY driver

[Vincent Whitchurch]

On Fri, Apr 05, 2019 at 10:39:43AM +0200, Enrico Weigelt, metux IT consult wrote:
> On 03.04.19 16:11, Vincent Whitchurch wrote:
> 
> > Especially on embedded systems, it would be convenient to have a simple
> > way to disable the console (both for kernel and userspace) on a system
> > which normally uses it, to free up the UART for other things.
> 
> Just symlinking to /dev/null does not work ?

No, /dev/null does not support the TTY ioctls.

> OTOH, if you're introducing a dummy console, wouldn't a ringbuffer that,
> can be read out later, a better option ?

There is already a ttyprintk driver in mainline to send these messages
to the printk ring buffer if one is actually intrested in what is
written to the console.  There's no option to enable it via console= in
mainline but I have a patch for that too.

Re: [PATCH] tty: Add NULL TTY driver

[Enrico Weigelt, metux IT consult]

On 05.04.19 11:00, Vincent Whitchurch wrote:
> On Fri, Apr 05, 2019 at 10:39:43AM +0200, Enrico Weigelt, metux IT consult wrote:
>> On 03.04.19 16:11, Vincent Whitchurch wrote:
>>
>>> Especially on embedded systems, it would be convenient to have a simple
>>> way to disable the console (both for kernel and userspace) on a system
>>> which normally uses it, to free up the UART for other things.
>>
>> Just symlinking to /dev/null does not work ?
> 
> No, /dev/null does not support the TTY ioctls.

hmm, wo (which programs) do you need, that really need them ?

>> OTOH, if you're introducing a dummy console, wouldn't a ringbuffer that,
>> can be read out later, a better option ?
> 
> There is already a ttyprintk driver in mainline to send these messages
> to the printk ring buffer if one is actually intrested in what is
> written to the console.  There's no option to enable it via console= in
> mainline but I have a patch for that too.

Great. IMHO, that would be the better way.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [PATCH] tty: Add NULL TTY driver

[Adamski, Krzysztof (Nokia - PL/Wroclaw)]

On Fri, Apr 05, 2019 at 02:32:41PM +0200, Enrico Weigelt, metux IT consult wrote:
>On 05.04.19 11:00, Vincent Whitchurch wrote:
>> On Fri, Apr 05, 2019 at 10:39:43AM +0200, Enrico Weigelt, metux IT consult wrote:
>>> On 03.04.19 16:11, Vincent Whitchurch wrote:
>>>
>>>> Especially on embedded systems, it would be convenient to have a simple
>>>> way to disable the console (both for kernel and userspace) on a system
>>>> which normally uses it, to free up the UART for other things.
>>>
>>> Just symlinking to /dev/null does not work ?
>>
>> No, /dev/null does not support the TTY ioctls.
>
>hmm, wo (which programs) do you need, that really need them ?
>
>>> OTOH, if you're introducing a dummy console, wouldn't a ringbuffer that,
>>> can be read out later, a better option ?
>>
>> There is already a ttyprintk driver in mainline to send these messages
>> to the printk ring buffer if one is actually intrested in what is
>> written to the console.  There's no option to enable it via console= in
>> mainline but I have a patch for that too.
>
>Great. IMHO, that would be the better way.

There are (embedded) cases where the kernel ring buffer is stored for
log inspection and all the logs that are *not* wanted there (like
interactive debug logs, some progress bar, etc) are send specifically to
/dev/console to avoid sending them to normal log store (as they are only
useful when debugging over console). In non-debug mode /dev/console
becomes /dev/null to speed things up.

I would personally benefit from Vincents patch. In fact I found this
thread because I was considering doing exactly the same for our system.

Krzysztof

Re: [PATCH] tty: Add NULL TTY driver

[Enrico Weigelt, metux IT consult]

On 11.04.19 15:05, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:

> There are (embedded) cases where the kernel ring buffer is stored for> log inspection and all the logs that are *not* wanted there (like>
interactive debug logs, some progress bar, etc) are send specifically
to> /dev/console to avoid sending them to normal log store (as they are
only> useful when debugging over console). In non-debug mode
/dev/console> becomes /dev/null to speed things up.
So, in your case, it doesn't need to be an actual tty, any file/chardev
already do it, correct ? But then, why is that new driver needed ?
--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [PATCH] tty: Add NULL TTY driver

[Adamski, Krzysztof (Nokia - PL/Wroclaw)]

On Fri, Apr 12, 2019 at 09:17:28AM +0200, Enrico Weigelt, metux IT consult wrote:
>On 11.04.19 15:05, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
>
>> There are (embedded) cases where the kernel ring buffer is stored for> log inspection and all the logs that are *not* wanted there (like>
>interactive debug logs, some progress bar, etc) are send specifically
>to> /dev/console to avoid sending them to normal log store (as they are
>only> useful when debugging over console). In non-debug mode
>/dev/console> becomes /dev/null to speed things up.
>So, in your case, it doesn't need to be an actual tty, any file/chardev
>already do it, correct ? But then, why is that new driver needed ?
>

Well, that depends. If the program doing those writes expects /dev/console
to be a tty device, then it cannot be any file. But, yes, there are usually
other ways of achieving this goal that do not involve adding kernel driver
but none of them is as convenient as having this kernel support. With this,
we can only switch kernel cmdline without any modifications to the rootfs.
The discussed kernel driver is very simple so there is little effort required
for this convenience. Maintaining it would be very easy and, of course,
anybody not needing it, can simply disable it in config so there is no cost.

Krzysztof

Re: [PATCH] tty: Add NULL TTY driver

[Enrico Weigelt, metux IT consult]

On 12.04.19 09:30, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:

> Well, that depends. If the program doing those writes expects /dev/console
> to be a tty device, then it cannot be any file. 

According to Vincent's mail, the actual problem is just systemd.
Changing the kernel just for making one specific userland program
(which happens to be written by somebody, who even doesn't know the
semantics of rm -R) happy, sounds pretty strange for me.

I'm not opposed to the general idea of having a dummy tty driver,
but please for some actually sane usecases, not just working around
broken userland :p


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [PATCH] tty: Add NULL TTY driver

[Adamski, Krzysztof (Nokia - PL/Wroclaw)]

On Fri, Apr 12, 2019 at 01:40:56PM +0200, Enrico Weigelt, metux IT consult wrote:
>On 12.04.19 09:30, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
>
>> Well, that depends. If the program doing those writes expects /dev/console
>> to be a tty device, then it cannot be any file.
>
>According to Vincent's mail, the actual problem is just systemd.
>Changing the kernel just for making one specific userland program
>(which happens to be written by somebody, who even doesn't know the
>semantics of rm -R) happy, sounds pretty strange for me.
>
>I'm not opposed to the general idea of having a dummy tty driver,
>but please for some actually sane usecases, not just working around
>broken userland :p

I don't want to start a flame but if that userspace would be written by
somebody else, would that change anything? :) Anyways, historically we
did not have many convinence usitlities in the kernel and now we do. So
does the fact that "this might be convinient but is not strictly
necessary" a blocker to get something into the kernel?

Krzysztof

Re: [PATCH] tty: Add NULL TTY driver

[Vincent Whitchurch]

On Fri, Apr 05, 2019 at 02:32:41PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 05.04.19 11:00, Vincent Whitchurch wrote:
> > On Fri, Apr 05, 2019 at 10:39:43AM +0200, Enrico Weigelt, metux IT consult wrote:
> >> On 03.04.19 16:11, Vincent Whitchurch wrote:
> >>
> >>> Especially on embedded systems, it would be convenient to have a simple
> >>> way to disable the console (both for kernel and userspace) on a system
> >>> which normally uses it, to free up the UART for other things.
> >>
> >> Just symlinking to /dev/null does not work ?
> > 
> > No, /dev/null does not support the TTY ioctls.
> 
> hmm, wo (which programs) do you need, that really need them ?

I think it was systemd's debug-shell which complained about the ioctls.

> >> OTOH, if you're introducing a dummy console, wouldn't a ringbuffer that,
> >> can be read out later, a better option ?
> > 
> > There is already a ttyprintk driver in mainline to send these messages
> > to the printk ring buffer if one is actually intrested in what is
> > written to the console.  There's no option to enable it via console= in
> > mainline but I have a patch for that too.
> 
> Great. IMHO, that would be the better way.

Like Krzysztof explained, sometimes you just want to discard these
messages.

Re: [PATCH] tty: Add NULL TTY driver

[Enrico Weigelt, metux IT consult]

On 11.04.19 17:28, Vincent Whitchurch wrote:

<snip>

>> hmm, wo (which programs) do you need, that really need them ?> > I think it was systemd's debug-shell which complained about the ioctls.
Okay, why not fixing this broken userland ?

systemd is written by somebody who doesn't even know the semantics of
rm  -R (as specified by unix standard since many decades) and so causing
funny things like complete disk wipe:

   https://github.com/systemd/systemd/issues/5644


In the last 25 years, I've always been fine w/ just redirecting to
/dev/null.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287