Reimplementing printk() [LWN.net]

Reimplementing printk()

Posted Feb 27, 2019 0:43 UTC (Wed) by gdt (subscriber, #6284)
Parent article: Reimplementing printk()

Options to make messages stand out more tend to be painful when automatically processing log messages. Kernel programmers are humans and want log output tuned for humans, but many more log readers are scripts using some sort of regular expression.

to post comments

Reimplementing printk()

Posted Feb 27, 2019 8:49 UTC (Wed) by jogness (subscriber, #49775) [Link] (3 responses)

The point of making emergency messages stand out is exactly for easier automatic processing. From the cover letter:

"Right now the emergency messages are set apart from the non-emergency messages using '\n'. There have been requests that some special markers could be specifiable to make it easier for parsers."

Reimplementing printk()

Posted Feb 27, 2019 9:24 UTC (Wed) by NAR (subscriber, #1313) [Link] (2 responses)

If logs are parsed by software, what about using a more structured log format like logmft? I guess this idea could be as controversial as systemd :-)

Reimplementing printk()

Posted Feb 27, 2019 9:42 UTC (Wed) by jani (subscriber, #74547) [Link]

> I guess this idea could be as controversial as systemd :-)

That part would be https://lwn.net/Articles/464276/

Reimplementing printk()

Posted Feb 27, 2019 20:54 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link]

Diagnostic output isn't supposed to be "parsed by software", that's usually just a crude attempt at getting around lack of an interfacen supposed to provided what said software really wants to have. Hence, optimizing the output format to make the crude workaround easier to implement at the expense of making the intended purpose (debugging) more complicated are a bad idea.

There's nothing "controversial" here, just lack of understanding.