On Thu 2020-10-01 00:39:31, Joe Perches wrote: > 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.
Yeah, pushing existing parts of continuous lines on the console would be nice. It would help to see that the system died in the middle of a risky operation. But it requires an extra code in the record based log buffer. It actually has been there and it was removed later because it complicated the code and did not really worked. It will be even more complicated with the lockless ringbuffer and console handled in kthreads. It might be added when there is a big demand for it. But it does not make sense to support looong lines full of spinners or dots. > There aren't many spinners/dots, perhaps it's better > to find and delete them. Yeah, that would be nice cleanup. Best Regards, Petr
