From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: OFFLIST: Re: [PATCH printk v2 6/7] printk: Use an output buffer descriptor struct for emit
Date: Thu, 24 Nov 2022 19:30:11 +0100 [thread overview]
Message-ID: <Y3+4MzIed3yLG4LE@alley> (raw)
In-Reply-To: <Y3+xK7hHmUIlzq9w@alley>
On Thu 2022-11-24 19:00:14, Petr Mladek wrote:
> PS: Please, wait a bit with updating the patches. I have got yet
> another idea when seeing the code around dropped messages.
> But I have to sleep over it.
>
> My concern is that the message about dropped messages need not
> fit into the smaller "cbufs->text" buffer. It might be better
> to put it into the bigger one.
>
> We might actually always use the bigger buffer as the output
> buffer. The smaller buffer might be only temporary when formatting
> the extended messages.
>
> We could replace
>
> struct console_buffers {
> char ext_text[CONSOLE_EXT_LOG_MAX];
> char text[CONSOLE_LOG_MAX];
> };
>
> with
>
> struct console_buffers {
> char outbuf[CONSOLE_EXT_LOG_MAX];
> char readbuf[CONSOLE_LOG_MAX];
> };
>
> Normal consoles would use only @outbuf. Only the extended console
> would need the @readbuf to read the messages before they are formatted.
>
> I guess that struct console_message won't be needed then at all.
>
> It might help to remove several twists in the code.
>
> I am sorry that I have not got this idea when reviewing v1.
> Well, the code was even more complicated at that time.
Honestly, I haven't looked if you extended struct console_messages in
later patches that added the atomic consoles. It is possible that
the structure will be needed in the end anyway.
This was just an idea. You know, I always try to simplify things.
And many layers, pointers to the same buffers with different names,
makes things complicated.
Well, there are always many ways how to design the code and I do not
want to delay it too much with trying them all. Please, tell me
when you think that some changes are not worth the effort.
Best Regards,
Petr
next prev parent reply other threads:[~2022-11-24 18:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 23:13 [PATCH printk v2 0/7] printk: cleanup buffer handling John Ogness
2022-11-23 23:13 ` [PATCH printk v2 1/7] printk: Move buffer size defines John Ogness
2022-11-24 11:09 ` Petr Mladek
2022-11-24 12:38 ` John Ogness
2022-11-24 14:42 ` Petr Mladek
2022-11-24 20:20 ` John Ogness
2022-11-23 23:13 ` [PATCH printk v2 2/7] console: Use BIT() macros for @flags values John Ogness
2022-11-24 11:14 ` Petr Mladek
2022-11-23 23:13 ` [PATCH printk v2 3/7] console: Document struct console John Ogness
2022-11-24 13:55 ` Petr Mladek
2022-11-23 23:13 ` [PATCH printk v2 4/7] printk: Add struct console_buffers John Ogness
2022-11-24 14:52 ` Petr Mladek
2022-11-24 20:22 ` John Ogness
2022-11-23 23:13 ` [PATCH printk v2 5/7] printk: Use " John Ogness
2022-11-24 15:22 ` Petr Mladek
2022-11-24 20:29 ` John Ogness
2022-11-23 23:13 ` [PATCH printk v2 6/7] printk: Use an output buffer descriptor struct for emit John Ogness
2022-11-24 18:00 ` Petr Mladek
2022-11-24 18:30 ` Petr Mladek [this message]
2022-11-24 21:15 ` John Ogness
2022-11-25 9:01 ` Petr Mladek
2022-11-25 10:49 ` John Ogness
2022-11-28 9:54 ` Petr Mladek
2022-11-23 23:14 ` [PATCH printk v2 7/7] printk: Handle dropped message smarter John Ogness
2022-12-07 12:50 ` Petr Mladek
2022-12-07 16:58 ` John Ogness
2022-12-08 9:29 ` 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=Y3+4MzIed3yLG4LE@alley \
--to=pmladek@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®