[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yk2mREN3JGjcpjRZ@alley>
Date: Wed, 6 Apr 2022 16:40:04 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v2 07/12] printk: move buffer definitions into
console_emit_next_record() caller
On Tue 2022-04-05 15:31:30, John Ogness wrote:
> Extended consoles print extended messages and do not print messages about
> dropped records.
>
> Non-extended consoles print "normal" messages as well as extra messages
> about dropped records.
>
> Currently the buffers for these various message types are defined within
> the functions that might use them and their usage is based upon the
> CON_EXTENDED flag. This will be a problem when moving to kthread printers
> because each printer must be able to provide its own buffers.
>
> Move all the message buffer definitions outside of
> console_emit_next_record(). The caller knows if extended or dropped
> messages should be printed and can specify the appropriate buffers to
> use. The console_emit_next_record() and call_console_driver() functions
> can know what to print based on whether specified buffers are non-NULL.
>
> With this change, buffer definition/allocation/specification is separated
> from the code that does the various types of string printing.
>
> Signed-off-by: John Ogness <john.ogness@...utronix.de>
I feel slightly sad that we replace the safe sizeof(buffer)
with a hardcoded size. But the change makes sense. And I think
that it is not worth passing the size as parameters.
Reviewed-by: Petr Mladek <pmladek@...e.com>
Best Regards,
Petr
Powered by blists - more mailing lists