[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZDgDhrnBJ3vSbxy8@alley>
Date: Thu, 13 Apr 2023 15:28:38 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: (k)thread: was: Re: [PATCH printk v1 11/18] printk: nobkl: Introduce
printer threads
On Thu 2023-03-02 21:02:11, John Ogness wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
>
> Add the infrastructure to create a printer thread per console along
> with the required thread function, which is takeover/handover aware.
>
Nit:
Several variable and function name use "thread"
+ con.thread_pbufs
+ con.write_thread()
+ printk_threads_enabled
and many others use "kthread":
+ con.kthread
+ con.kthread_waiting
+ cons_kthread_wake()
+ cons_kthread_create()
+ cons_kthread_should_wakeup()
I do not see any pattern. It would be nice to choose just one variant
for the cons/printk API. I slightly prefer "kthread" but "thread"
would be fine as well.
When we are on the (k)thread naming stuff. We talk about it
historically as a printk (k)thread. But I often feels that it
rather should be a console (k)thread, especially when we have
one per console.
That said, both variants make sense. The thread is used for showing
messages from the printk ring buffer.
Best Regards,
Petr
Powered by blists - more mailing lists