Re: [PATCH v2 2/4] btrfs: make __btrfs_dump_space_info() output better formatted

[Sweet Tea Dorminy <sweettea-kernel@dorminy.me>]

On 7/26/22 19:21, Boris Burkov wrote:
> On Tue, Jul 26, 2022 at 11:39:28PM +0200, David Sterba wrote:
>> On Tue, Jul 26, 2022 at 01:53:33PM -0700, Boris Burkov wrote:
>>>> Yes we shold care about readability but kernel printk output lines can
>>>> be interleaved, single line is much easier to grep for and all the
>>>> values are from one event. The format where it's a series of "key=value"
>>>> is common and I think we're used to it from tracepoints too. There are
>>>> lines that do not put "=" between keys and values we could unify that
>>>> eventually.
>>>
>>> Agreed that a long line is OK, and preferable to full on splitting.
>>>
>>> What about making some btrfs printing macros that use KERN_CONT? I think
>>> that would do what Qu wants without splitting the lines or being bad for
>>> ratelimiting.
>>
>> IIRC I've read some discussions about KERN_CONT suggesting not to use
>> it, I'll ask what's the status.
> 
> I just saw a comment at its definition that reads:
> 
> /*
>   * Annotation for a "continued" line of log printout (only done after a
>   * line that had no enclosing \n). Only to be used by core/arch code
>   * during early bootup (a continued line is not SMP-safe otherwise).
>   */
> #define KERN_CONT       KERN_SOH "c"
> 
> So that's not an encouraging sign. OTOH, I found some code in
> ext4/super.c that prints its errors with KERN_CONT here:
> 'ext4: super.c: Update logging style using KERN_CONT

Some other log message from somewhere else could be emitted to the 
printk ringbuffer between the original and the continued message. In 
such a case, the continued message instead gets treated as its own 
message of loglevel default. (kernel/printk/printk.c:2173ish) Using 
KERN_CONT seems like it has a lot of potential for confusion, especially 
if the default message level has been changed to be different from the 
original messages' level.