lkml.org 
[lkml]   [2021]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ttyprintk: Add TTY hangup callback.
From
Date
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

\
 
 \ /
  Last update: 2021-04-27 13:33    [W:0.195 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site