Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH printk v1 11/13] printk: reimplement console_lock for proper kthread support | Date | Mon, 14 Mar 2022 15:49:39 +0106 |
| |
On 2022-03-14, Petr Mladek <pmladek@suse.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
| |