Messages in this thread | | | Subject | Re: [PATCH] ttyprintk: Add TTY hangup callback. | From | Samo Pogačnik <> | Date | Mon, 26 Apr 2021 18:42:05 +0200 |
| |
Dne 26.04.2021 (pon) ob 12:00 +0200 je Petr Mladek napisal(a): > On Sat 2021-04-24 11:57:47, Samo Pogačnik wrote: > > Dne 24.04.2021 (sob) ob 10:16 +0900 je Tetsuo Handa napisal(a): > > > On 2021/04/24 4:47, Samo Pogačnik wrote: > > > > At any point the tpk_buffer is potentially multiplexed/interleaved by > > > > parts > > > > of > > > > required output of any concurrent user, as buffs are being delivered by > > > > the > > > > scheduled writes. > > > > > > As long as one line is printed by one printk() call, > > > CONFIG_PRINTK_CALLER=y is > > > helpful enough to distinguish multilplexed/interleaved messages. I > > > consider > > > that > > > ttyprintk offers additional advantage over printk() for allow buffering > > > one > > > line > > > of message from userspace. > > It does not matter how much buffering games you play. As long as you > use printk() to store single lines into the kernel logbuffer they > alway could be interleaved with lines from other processes/CPUs.
Exactly. The only purpose of ttyprintk buffering is to mark any begining of lines occurring within the userspace-string written into ttyprintk TTY. The marked lines do not originate in the kernel source code, which is not obvious otherwise (imho this is importannt). Even the CONFIG_PRINTK_CALLER=y does not give this information, if the task ID printed does not live anymore.
> > > > > > > > > As per user buffers look promising with output formatting, the FDs > > > > passing > > > > between tasks lead to the same single buffer (Greg already mentioned > > > > that). > > > > > > Those programs which use FD passing know what they are doing. If they > > > still > > > want > > > one line of message printed via ttyprintk interface, they must do their > > > buffering > > > before trying to write() to ttyprintk's file descriptor. > > Lines might get interleaved when using printk(). > What is special about messages passed via ttyprintk()? They do not originate in the kernel code.
> How many processes are using it? In case of redirection any proces, that is writing to console.
> Do they print many lines? ?
> Is it really worth any added complexity? No.
> > > On the other hand, my main concern is how to provide a reliable system wide > > collection of all console output via ttyprintk console redirection, while > > normal > > operation of system console is preserved (except its output being detoured > > via > > printk and as such logged together with kernel output). Such logging is > > particularly useful for after-the-fact inspection of system operation. > > I am not sure if I understand the problem. But why does ttyprintk need > any buffer at all. AFAIK, the use-case is to pass any written data into the > kernel logbuffer via printk()? (see above - it is not something the kernel is telling you) > > Why tpk_write() does not call printk() directly? (see above) > > If you call printk() directly, the caller_id would be from the process > that really wrote the data/message. It can be a kernel-code originating message printk-ed on behalf of a user task or a kernel-code originating message on behalf of a kernel task. Or it may be a user-code originating message on behalf of its task, when printk-ed via ttyprintk.
> > > That being said i am thinking about how to permanently enable this > > redirection > > as early as possible (i.e. via kernel command line option). I had a working > > prototype for that some time ago (never posted). Would anybody like to see > > such > > functionality? > > Please, do not add any complex code if it does not cause real life > problems. > Noted, thanks.
Best regards, Samo
| |