[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h780y4pw.fsf@jogness.linutronix.de>
Date: Mon, 14 Mar 2022 15:49:39 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
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: Re: [PATCH printk v1 11/13] printk: reimplement console_lock for
proper kthread support
On 2022-03-14, Petr Mladek <pmladek@...e.com> wrote:
> My intention is to keep the logic as simple and as clear as possible:
>
> + if we need lock then use lock
>
> + if we need trylock then use trylock
>
> + if we want direct mode then block kthreads and try enter
> the direct mode ASAP.
>
> + if kthreads mode is allowed then do nothing in
> console_unlock() and leave the job to kthreads.
>
> + console_lock() temporarily blocks kthreads but
> it handle messages only when direct mode is enforced.
Thank you for your examples, detailed analysis, insight, and summaries.
This particular review became quite complicated because offline you sent
me a heavily revised version. Several of your comments are criticizing
your version and not the actual series I posted. For v2 we need to
handle it better so that the list has a chance at following our
discussion. ;-)
I will post a v2 that attempts to address your concerns and try to frame
the naming and structures to align with your suggestions.
John
Powered by blists - more mailing lists