Re: highlighted kernel messages on serial console
David Brownlee <[email protected]> Sun, 2 Aug 2026 20:59:56 +0100
| Newsgroups | gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <CAGN_6pYSskOpDd0kmy1+i_puAmFqfF87WAWqhzAdcNJKpU45Wg@mail.gmail.com> |
On Sun, 2 Aug 2026 at 20:43, Timo Buhrmester <[email protected]> wrote: > > While playing around with the prefix/suffix concept, essentially after > the first attempt with prefix 'foo' and suffix 'bar', and getting: > | foo[timestamp] kernel message > | bar > I realized that kernel messages are already suffixed, by newlines, so > that would there be a reasonable choice for the default value of the > suffix. Or so my initial thought was. > > Of course, the concept of kernel messages being produced in the form > of lines is an assumption that reaches into pretty much any source file > in the form of printf("...\n"). > > Now, despite my DS9k operating out of spec unless kernel messages are > terminated by "</krnlmsg>" base64'ed and beeped out in Morse code on > the terminal fog horn -- where newlines really just get in the way of > the 45-degree rotated console displaying lines holographically in the > Z direction -- removing every \n all throughout the kernel doesn't seem > reasonable. Besides, it would cause problems with messages that are > produced from multiple printfs). > > What's everybody's thoughts on that matter? Live with the fact that the > suffix will be, so to speak, prefixed by \n? Or scan what is being > printed in order to insert the suffix before the newline? Any other > approaches or ideas that come to mind? There is a further complication that sometimes a message line may come from multiple print statements. Though... sometimes two problems can provide an opportunity. Could the kernel print mechanism use the presence of \n in output to track lines? Add an inLine boolean to track. If false, send the start sequence and switch to true. On detection of \n switch to false and output end sequence (potentially skipping the \n in the output) Presumably would need to be per cpu to avoid cross cpu locking... David