From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk v3 6/6] printk: introduce console_prepend_dropped() for dropped messages
Date: Tue, 03 Jan 2023 16:06:03 +0106 [thread overview]
Message-ID: <87fscrd5os.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <Y7Q4u9ICptw0RnXb@alley>
On 2023-01-03, Petr Mladek <pmladek@suse.com> wrote:
>> Actually, I would like to rename all of those limit macros to something
>> that makes more sense for the new code base:
>>
>> CONSOLE_EXT_LOG_MAX -> CONSOLE_MESSAGE_MAX
>>
>> CONSOLE_LOG_MAX -> SYSLOG_MESSAGE_MAX
>
> Heh, we actually do not need this. The size of @scratchbuf
> might be LOG_LINE_MAX/PRINTK_RECORD_MAX. The scratch buffer
> is newly used only to read the plain message. The prefixes
> are added to @outbuf.
>
>> LOG_LINE_MAX -> PRINTK_RECORD_MAX
The scratch buffer would become PRINTK_RECORD_MAX, but we still need
SYSLOG_MESSAGE_MAX for the kmalloc's syslog buffers. Unless you think it
is OK to kmalloc 8KB instead of 1KB for the syslog calls. Then yes, we
do not need SYSLOG_MESSAGE_MAX.
John
next prev parent reply other threads:[~2023-01-03 15:00 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 20:26 [PATCH printk v3 0/6] printk: cleanup buffer handling John Ogness
2022-12-21 20:26 ` [PATCH printk v3 1/6] printk: move size limit macros into internal.h John Ogness
2023-01-02 14:06 ` Petr Mladek
2022-12-21 20:27 ` [PATCH printk v3 2/6] console: Use BIT() macros for @flags values John Ogness
2022-12-21 20:27 ` [PATCH printk v3 3/6] console: Document struct console John Ogness
2022-12-21 20:27 ` [PATCH printk v3 4/6] printk: introduce struct console_buffers John Ogness
2023-01-02 15:15 ` Petr Mladek
2023-01-03 10:04 ` John Ogness
2022-12-21 20:27 ` [PATCH printk v3 5/6] printk: introduce console_get_next_message() and console_message John Ogness
2022-12-22 15:41 ` John Ogness
2023-01-03 14:04 ` Petr Mladek
2023-01-03 14:57 ` John Ogness
2023-01-03 15:55 ` Petr Mladek
2023-01-04 10:26 ` John Ogness
2023-01-04 10:42 ` Petr Mladek
2023-01-02 15:52 ` Petr Mladek
2023-01-03 15:41 ` John Ogness
2023-01-03 10:02 ` John Ogness
2023-01-03 14:05 ` Petr Mladek
2022-12-21 20:27 ` [PATCH printk v3 6/6] printk: introduce console_prepend_dropped() for dropped messages John Ogness
2023-01-02 16:19 ` Petr Mladek
2023-01-03 10:20 ` John Ogness
2023-01-03 13:29 ` Petr Mladek
2023-01-03 13:44 ` John Ogness
2023-01-03 14:16 ` Petr Mladek
2023-01-03 15:00 ` John Ogness [this message]
2023-01-03 16:13 ` Petr Mladek
2023-01-04 9:06 ` John Ogness
2023-01-04 10:33 ` Petr Mladek
2023-01-05 13:14 ` kernel test robot
2023-01-05 13:55 ` John Ogness
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=87fscrd5os.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.