Messages in this thread | | | Date | Mon, 14 Mar 2022 16:53:20 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH printk v1 11/13] printk: reimplement console_lock for proper kthread support |
| |
On Mon 2022-03-14 15:49:39, John Ogness wrote: > 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 am really sorry for this. And some my mails also were a bit misleading because I missed something in the code.
One small plus is that most of the new names were mentioned in the public https://lore.kernel.org/r/YhYKP/UuSKENGwfj@alley But I agree that I probably made it more confusing than needed.
> I will post a v2 that attempts to address your concerns and try to frame > the naming and structures to align with your suggestions.
Yes, sending v2 and continuing the discussion sounds like a good idea.
Best Regards, Petr
| |