[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1e3164eabf69e04ad9e9ddc259ca685f48c5e27.camel@perches.com>
Date: Wed, 19 Aug 2020 17:33:51 -0700
From: Joe Perches <joe@...ches.com>
To: John Ogness <john.ogness@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/5] printk: implement pr_cont_t
On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
> Implement a new buffering mechanism for pr_cont messages.
>
> Old mechanism syntax:
>
> printk(KERN_INFO "text");
> printk(KERN_CONT " continued");
> printk(KERN_CONT "\n");
>
> New mechanism syntax:
>
> pr_cont_t c;
>
> pr_cont_begin(&c, KERN_INFO "text");
bikeshed:
I suggest:
printk_begin(&printk_context, fmt, ...)
printk_continue(&printk_context, fmt, ...) (maybe printk_next())
printk_end(&printk_context, fmt, ...)
and macros using pr_<level>_begin
ie:
#define pr_info_begin(context, fmt, ...) \
printk_begin(context, KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
and each continued bit would use printk_continue or printk_end
as appropriate.
KERN_<LEVEL> could be a separate argument, but it's simple
enough to use
printk_get_level on the format.
Powered by blists - more mailing lists