[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHcoNgbDyMbDKSf1@alley>
Date: Wed, 14 Apr 2021 19:36:54 +0200
From: Petr Mladek <pmladek@...e.com>
To: Samo Pogačnik <samo_pogacnik@....net>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Jiri Slaby <jirislaby@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
John Ogness <john.ogness@...utronix.de>,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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
Powered by blists - more mailing lists