2003 Kernel Summit: Error Logging

• The kernel should generate event data which is parseable by other programs.

• It also needs to generate messages which can be parsed by humans.

• All this should happen without an undue burden on the kernel developers.

Suparna put up a quick description of an error reporting API which makes use of the netlink interface to communicate with user-space. This API (which has been posted to the net before) adds two new functions (evl_write() and evl_printf()) which would be used, in place of printk(), to report events and errors. The evl_ functions include a fair amount of metainformation, including event type and facility codes, in the hope of adding a certain amount of structure to kernel event reporting.

This interface was not particularly well received. Why not, it was asked, just use printk() strings? Adding numeric event type codes was seen as a bit of a mistake; most developers, it would seem, would rather just see the information encoded as strings that humans can read. It was also pointed out that a netlink-based interface requires a user-space daemon to receive and process the messages. But that daemon could well be rendered unavailable by the same problem that the kernel is trying to report.

The discussion headed toward providing enhanced versions of printk() (such as the relatively new dev_printk()) which provide the relevant information in a standard form without requiring much work on the developer's part. Expect to see more printk() variants in the 2.7 development cycle.