Messages in this thread | | | From | David Laight <> | Subject | RE: [RFC PATCH 1/5] printk: implement pr_cont_t | Date | Thu, 20 Aug 2020 12:33:23 +0000 |
| |
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.
Unexpected pr_cont() could be output with a leading "... " to help indicate the message is a continuation.
> 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.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |