Messages in this thread Patch in this message | | | Date | Wed, 17 Apr 2019 18:46:14 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v2] panic: add an option to replay all the printk message in buffer |
| |
On (04/17/19 11:18), Petr Mladek wrote: > > My instant thought would be put the console_unlcok() and similar funcs > > under CONFIG_PRINTK protection, while adding nop functions in the "else" > > segment. > > > > But complexer question will be when CONFIG_PRINTK=n, how those console_xxx > > functions should consider these to make compiled binary smaller (though it > > rarely happens). would wait for Petr/Sergey/Steven's insights. > > I guess that it is because console_sem is historically used to > synchronize some unrelated things, espcially in tty code. > Unfortunately, it is not easy to clean this up. > > For this patch, the best solution seems to be using scnprintf() > instead of sprintf().
OK, since we have another chance to re-iterate this. Do we really want to complicate console_unlock() printing loop any further? Asking off chance, can we return back to the idea of adding enum FLUSH_PENDING/FLUSH_ALL to console_flush_on_panic()?
Does not look too complex/ugly.
--- -void console_flush_on_panic(void) +void console_flush_on_panic(enum console_flush_mode flush_mode) { /* * If someone else is holding the console lock, trylock will fail @@ -2549,6 +2549,10 @@ void console_flush_on_panic(void) */ console_trylock(); console_may_schedule = 0; + if (flush_mode == FLUSH_ALL) { + console_seq = log_first_seq; + console_idx = log_first_idx; + } console_unlock(); } --- -ss
| |