Re: [RFC PATCH 1/5] printk: implement pr_cont_t

[Petr Mladek <pmladek@suse.com>]

On Thu 2020-08-20 12:33:23, David Laight wrote:
> From: Petr Mladek
> > Sent: 20 August 2020 11:16
> ...
> > Now that I think about it. This is the biggest problem with any temporary buffer
> > for pr_cont() lines. I am more and more convinced that we should just
> > _keep the current behavior_. It is not ideal. But sometimes mixed
> > messages are always better than lost ones.
> 
> Maybe a marker to say 'more expected' might be useful.
> OTOH lack of a trailing '\n' probably signifies that a
> pr_cont() is likely to be next.

The problem is the "probably". Lack of trailing '\n' might also mean
that the author did not care. Note that newline is not strictly
required at the moment. The next message is concatenated only when
pr_cont() is used from the same process.

I would personally hate printk when I debugged some hard-to-reproduce
bug, finally succeeded, and some message was missing just because
of a missing newline.


> Unexpected pr_cont() could be output with a leading "... "
> to help indicate the message is a continuation.

Interesting idea. It might help to catch broken code. Well, I am still
not sure that people would appreciate this printk() behavior.


> > That said, some printk() API using local buffer would be still
> > valuable for pieces of code where people really want to avoid
> > mixed lines. But it should be optional and people should be
> > aware of the risks.
> 
> That could be very useful if it supported multi-line output.
> Thing like the stack backtrace code could use it avoid
> the mess that happens when multiple processes generate
> tracebacks at the same time.

Honestly, I am going to push against it. I agree that would be useful
but it is an evil path.

There has to be some limits. Backtraces are often printed in situation
where the buffer could not get allocated dynamically. There always
be a situation when a buffer will not be big enough.

If we add this feature, people will want to use it also for other
purposes that might need even bigger buffers and the size might
be even harder to predict.

And the temporary buffer is only part of the problem. The message also
has to be stored into the lockless ringbuffer, show on consoles, passed
to userspace, stored during panic by pstore.

The printk() design already is very complicated. And multiple lines
support would stretch it in yet another dimension.

And it is going to be less important. We are going to always store the
information about the printk caller. So that it will be much easier
to grep related lines.

Best Regards,
Petr