2021-04-12 12:53:40

by Samo Pogačnik

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> What is the intended usage of /dev/ttyprintk ?
>

The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
via the TIOCCONS ioctl. After successfull redirection, all console
messages get "merged" with kernel messages and as such automatically processed
(stored/transferred) by the syslog service for example.

best regards, Samo



2021-04-13 14:16:38

by Petr Mladek

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > What is the intended usage of /dev/ttyprintk ?
> >
>
> The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> via the TIOCCONS ioctl. After successfull redirection, all console
> messages get "merged" with kernel messages and as such automatically processed
> (stored/transferred) by the syslog service for example.

The same can be achieved by /dev/kmsg that was created by systemd
developers.

systemd is able to flood the kernel buffer and consoles.
It can be protected by ratelimiting, see the commit
750afe7babd117daabebf ("printk: add kernel parameter
to control writes to /dev/kmsg").

/dev/kmsg ratelimit is a "must-to-have". systemd enables debug
messages using the same "debug" parameter passed on the kernel
commandline. The ratelimit allows to see the kernel messages.

Note that the ratelimit is enabled by default by kernel. But it
it disabled by default by systemd. So, it is effectively disabled
by default.

It might be possible to add retalimiting also for /dev/ttyprintk.
But does it make sense just because of an artifical test case?


History:

/dev/ttyprintk has been added in v2.6.37 (2010) by commit 24b4b67d17c308aaa956b
("add ttyprintk driver")

/dev/kmsg has been add in v3.5-rc1 (2012) by commit e11fea92e13fb91c50ba
("kmsg: export printk records to the /dev/kmsg interface")

Another solution might be to obsolete /dev/ttyprintk by /dev/kmsg.
We have to preserve /dev/kmsg because of systemd.
Is anyone really using /dev/ttyprintk these days?

Best Regards,
Petr

2021-04-13 14:44:14

by Samo Pogačnik

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > > What is the intended usage of /dev/ttyprintk ?
> > >
> >
> > The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> > via the TIOCCONS ioctl. After successfull redirection, all console
> > messages get "merged" with kernel messages and as such automatically
> > processed
> > (stored/transferred) by the syslog service for example.
>
> The same can be achieved by /dev/kmsg that was created by systemd
> developers.
>
'kmsg' and 'ttyprintk' are different types of drivers and as such rather
complementary than exclusive. The 'ttyprintk' being a tty driver allows
for a system wide automatic redirection of anything written to the console.
On the other hand 'kmsg' is probably better suited for a per process
output redirection/injection of its output into kernel messages.

Maybe i am wrong, but 'systemd' could also find 'ttyprintk' usefull?

best regards, Samo



2021-04-13 20:39:26

by Petr Mladek

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote:
> Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> > On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> > > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > > > What is the intended usage of /dev/ttyprintk ?
> > > >
> > >
> > > The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> > > via the TIOCCONS ioctl. After successfull redirection, all console
> > > messages get "merged" with kernel messages and as such automatically
> > > processed
> > > (stored/transferred) by the syslog service for example.
> >
> > The same can be achieved by /dev/kmsg that was created by systemd
> > developers.
> >
> 'kmsg' and 'ttyprintk' are different types of drivers and as such rather
> complementary than exclusive. The 'ttyprintk' being a tty driver allows
> for a system wide automatic redirection of anything written to the
> console.

I might miss something. But how can one setup ttyprintk as the system
wide console? I do not see any code that would use ttyprintk
in struct console.

Or am I too focused on the printk/kernel-side of view?

> On the other hand 'kmsg' is probably better suited for a per process
> output redirection/injection of its output into kernel messages.

> Maybe i am wrong, but 'systemd' could also find 'ttyprintk' usefull?

/dev/kmsg allows both read and write from/to the kernel log buffer.

The write callback allows to pass a certain loglevel from the
user space in the format "<level>message"

The read callback passes a lot of meta information in the format
"<level>,<sequnum>,<timestamp>,<contflag>[,additional_values,
... ];<message text>\n"

IMHO, /dev/kmsg provides a super set of functionality
over /dev/ttyprintk. But I am not familiar with the tty layer
and all its use-cases.

To make it clear. I do not resist on removing ttyprintk by any means.
It was just an idea. I am not even sure if it is possible to obsolete
tty drivers.

Best Regards,
Petr

2021-04-14 01:22:27

by Samo Pogačnik

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

Dne 13.04.2021 (tor) ob 16:32 +0200 je Petr Mladek napisal(a):
> On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote:
> > Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> > > On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> > > > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > > > > What is the intended usage of /dev/ttyprintk ?
> > > > >
> > > >
> > > > The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> > > > via the TIOCCONS ioctl. After successfull redirection, all console
> > > > messages get "merged" with kernel messages and as such automatically
> > > > processed
> > > > (stored/transferred) by the syslog service for example.
> > >
> > > The same can be achieved by /dev/kmsg that was created by systemd
> > > developers.
> > >
> >
> > 'kmsg' and 'ttyprintk' are different types of drivers and as such rather
> > complementary than exclusive. The 'ttyprintk' being a tty driver allows
> > for a system wide automatic redirection of anything written to the
> > console.
>
> I might miss something. But how can one setup ttyprintk as the system
> wide console? I do not see any code that would use ttyprintk
> in struct console.
>

You can compile this simple code below and call:

# ./tioccons /dev/ttyprintk

... from now on all console output interleaves the kernel log (you can check
dmesg or logs)

# ./tioccons /dev/console

... sets things back they were.

You will be able to recognize console messages by preceding "[U]" tag (meaning
User).

-------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>

int main(int argc, char **argv)
{
int fd;

if (argc != 2) {
printf("Wrong usage!\n");
exit(1);
}

if ((fd = open(argv[1], O_WRONLY)) == -1) {
perror(argv[1]);
exit(1);
}

if (ioctl(fd, TIOCCONS, NULL) == -1) {
printf("ioctl: %s\n", strerror(errno));
exit(1);
}

exit(0);
}
--------------------

best regards, Samo

2021-04-15 00:39:04

by Petr Mladek

[permalink] [raw]
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

On Tue 2021-04-13 17:22:46, Samo Pogačnik wrote:
> Dne 13.04.2021 (tor) ob 16:32 +0200 je Petr Mladek napisal(a):
> > On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote:
> > > Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> > > > On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> > > > > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > > > > > What is the intended usage of /dev/ttyprintk ?
> > > > > >
> > > > >
> > > > > The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> > > > > via the TIOCCONS ioctl. After successfull redirection, all console
> > > > > messages get "merged" with kernel messages and as such automatically
> > > > > processed
> > > > > (stored/transferred) by the syslog service for example.
> > > >
> > > > The same can be achieved by /dev/kmsg that was created by systemd
> > > > developers.
> > > >
> > >
> > > 'kmsg' and 'ttyprintk' are different types of drivers and as such rather
> > > complementary than exclusive. The 'ttyprintk' being a tty driver allows
> > > for a system wide automatic redirection of anything written to the
> > > console.
> >
> > I might miss something. But how can one setup ttyprintk as the system
> > wide console? I do not see any code that would use ttyprintk
> > in struct console.
> >
>
> You can compile this simple code below and call:
>
> # ./tioccons /dev/ttyprintk

Thanks a lot for the example.

My head is still spinning around it. I have troubles to update
my mental model around /dev/console with this use case.

My original model is that kernel or processes write into
/dev/console so that a human could see and read it
on the device attached to the console.

kernel is calling console->write() callback when showing new messages
on consoles. The write to the redirected /dev/console
makes the messages appear in the kernel log. It feels like
it should create an infinite loop. Except that it doesn't
work this way. Sigh.

Best Regards,
Petr