Messages in this thread | | | Subject | Re: [PATCH] ttyprintk: Add TTY hangup callback. | From | Samo Pogačnik <> | Date | Tue, 27 Apr 2021 13:31:30 +0200 |
| |
Dne 27.04.2021 (tor) ob 12:08 +0200 je Petr Mladek napisal(a): > > I guess that you mean TPK_PREFIX + "[U] ". yes
> > 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. The string received in tpk_write() has no guaranties, that it represents a complete output line. It has to be treated as a sub-string of a potentially multi-line massage produced by the userspace code/process.
The tpk_close() only produces additional output (flush), if the last tpk_write() string does not end with some end-of-line indication.
> > > > > > > > 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(). > IMHO, it is good that output provides info about all the above cases and especially that particular output is not produced by the kernel code itself.
best regards, samo
| |