Messages in this thread | | | Date | Tue, 27 Apr 2021 12:08:08 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH] ttyprintk: Add TTY hangup callback. |
| |
On Mon 2021-04-26 18:42:05, Samo Pogačnik wrote: > Dne 26.04.2021 (pon) ob 12:00 +0200 je Petr Mladek napisal(a): > > 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.
I guess that you mean TPK_PREFIX + "[U] ".
> > 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)
But you could do this already in tpk_write(). I mean that you could parse the given buffer, copy each line to a temporary buffer, and call printk(TPK_PREFIX "[U] %s\n", tmp_buf).
Why is it postponed to tpk_close()?
IMHO, the printk() in tpk_write() might simplify the logic a bit.
> > 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.
Exactly. Now, I am not sure if you think that this good or bad.
IMHO, it is much better to use caller_id of the process/context that wrote the data/message instead of the process that caused the final tpk_close().
Anyway, it is not a big deal. We could leave the code as is if it works for you. My mine intention was to stop the ideas of per-task buffers and additional complexity. It was just an idea how to simplify the code instead.
Best Regards, Petr
| |