On Thu, 2020-10-01 at 09:26 +0200, Petr Mladek wrote: > On Wed 2020-09-30 08:25:24, Joe Perches wrote: > > On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote: > > > If a reader provides a buffer that is smaller than the message text, > > > the @text_len field of @info will have a value larger than the buffer > > > size. If readers blindly read @text_len bytes of data without > > > checking the size, they will read beyond their buffer. > > > > > > Add this check to record_print_text() to properly recognize when such > > > truncation has occurred. > > > > > > Add a maximum size argument to the ringbuffer function to extend > > > records so that records can not be created that are larger than the > > > buffer size of readers. > > > > > > When extending records (LOG_CONT), do not extend records beyond > > > LOG_LINE_MAX since that is the maximum size available in the buffers > > > used by consoles and syslog. > > > > I still think it better to support backspace by rewinding > > the buffer rather than truncation of the output. > > IMHO, backspace support is not worth the complexity. It might do > some fancy animation on console but it does not bring any advantage > in static logs (dmesg, journalctl). > > It is possible that it worked in the past when the log buffer was > just an array of characters that were pushed to the console when > they appeared. > > But I am pretty sure that it has stopped working many years agl > variable-length record buffer").
It's more that spinner or timer dots could fill the buffer and any message after the spinner/dots like success or failure is lost via truncation. There aren't many spinners/dots, perhaps it's better to find and delete them.
