From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk-rework 05/14] printk: introduce CONSOLE_LOG_MAX for improved multi-line support
Date: Fri, 19 Feb 2021 13:44:05 +0100 [thread overview]
Message-ID: <YC+ylZ3scs0cZfmt@alley> (raw)
In-Reply-To: <20210218081817.28849-6-john.ogness@linutronix.de>
On Thu 2021-02-18 09:18:08, John Ogness wrote:
> Instead of using "LOG_LINE_MAX + PREFIX_MAX" for temporary buffer
> sizes, introduce CONSOLE_LOG_MAX. This represents the maximum size
> that is allowed to be printed to the console for a single record.
>
> Rather than setting CONSOLE_LOG_MAX to "LOG_LINE_MAX + PREFIX_MAX"
> (1024), increase it to 4096. With a larger buffer size, multi-line
> records that are nearly LOG_LINE_MAX in length will have a better
> chance of being fully printed. (When formatting a record for the
> console, each line of a multi-line record is prepended with a copy
> of the prefix.)
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
The logic is correct. I am just slightly afraid that people
developing small devices might cry. And nobody reported problems
with the small buffer.
OK, let's try the change. We could always revert the size increase
when anyone complains.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
next prev parent reply other threads:[~2021-02-19 12:45 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 8:18 [PATCH printk-rework 00/14] printk: remove logbuf_lock John Ogness
2021-02-18 8:18 ` [PATCH printk-rework 01/14] printk: limit second loop of syslog_print_all John Ogness
2021-02-18 16:15 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 02/14] printk: kmsg_dump: remove unused fields John Ogness
2021-02-18 16:18 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 03/14] printk: refactor kmsg_dump_get_buffer() John Ogness
2021-02-18 8:18 ` [PATCH printk-rework 04/14] printk: consolidate kmsg_dump_get_buffer/syslog_print_all code John Ogness
2021-02-19 12:28 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 05/14] printk: introduce CONSOLE_LOG_MAX for improved multi-line support John Ogness
2021-02-19 12:44 ` Petr Mladek [this message]
2021-02-18 8:18 ` [PATCH printk-rework 06/14] printk: use seqcount_latch for clear_seq John Ogness
2021-02-18 8:18 ` [PATCH printk-rework 07/14] printk: use atomic64_t for devkmsg_user.seq John Ogness
2021-02-19 12:59 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 08/14] printk: add syslog_lock John Ogness
2021-02-19 13:30 ` Petr Mladek
2021-02-19 14:45 ` John Ogness
2021-02-19 16:33 ` John Ogness
2021-02-21 21:39 ` Helge Deller
2021-02-22 16:28 ` Petr Mladek
2021-02-23 12:22 ` Helge Deller
2021-02-23 14:23 ` Petr Mladek
2021-02-23 14:45 ` Helge Deller
2021-02-22 16:05 ` Petr Mladek
2021-02-22 16:43 ` John Ogness
2021-02-23 14:38 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 09/14] printk: introduce a kmsg_dump iterator John Ogness
2021-02-19 15:56 ` Petr Mladek
2021-02-19 16:50 ` Michael Kelley
2021-02-19 17:57 ` synchronization model: was: " Petr Mladek
2021-02-24 12:27 ` John Ogness
2021-02-24 15:40 ` John Ogness
2021-02-25 12:33 ` Petr Mladek
2021-02-26 8:36 ` John Ogness
2021-02-26 9:48 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 10/14] um: synchronize kmsg_dumper John Ogness
2021-02-18 8:18 ` [PATCH printk-rework 11/14] printk: remove logbuf_lock John Ogness
2021-02-23 11:44 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 12/14] printk: kmsg_dump: remove _nolock() variants John Ogness
2021-02-23 11:51 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 13/14] printk: kmsg_dump: use kmsg_dump_rewind John Ogness
2021-02-23 11:53 ` Petr Mladek
2021-02-18 8:18 ` [PATCH printk-rework 14/14] printk: console: remove unnecessary safe buffer usage John Ogness
2021-02-23 12:55 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YC+ylZ3scs0cZfmt@alley \
--to=pmladek@suse.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox